❌

Reading view

There are new articles available, click to refresh the page.

My Week in Beagle #5

✇BeagleBoard
By: Ayush Singh

Hello everyone. I was busy with the Linux kernel for most of the week. Let’s go over everything.

Devicetree append properties support

Currently, devictree supports creating and deleting properties but not appending to existing properties. This functionality is vital for complex uses like MikroBUS. I have been working on this for a while and posted Patch v3 last week.

To understand what it allows, let’s take an example:

dts-v1/;

/ {
    node {
        str-prop = "0";
    };
};

/ {
    node {
        /append-property/ str-prop = "1";
    };
};

The above devictree will produce the following output:

dts-v1/;

/ {
    node {
        str-prop = "0", "1";
    };
};

Devicetree overlays path reference support

Devicetree allows references in two contexts:

  1. Integer context: In this case the references are resolved to phandle. 
    foo = <&bar>;
  2. String context: In this case, the references are resolved to paths. 
    foo = &bar;

Runtime overlays only support the former but not the latter. I have created a patch series to fix this asymmetry.

Additionally, __symbols__ does not support phandles, which makes overlays modifying __symbols__ somewhat limiting. More context regarding this patch can be found here.

Ending Thoughts

This was it for this week. Hopefully, this helps bring transparency regarding where the development efforts are concentrated, and how the community can help. Look forward to next update.

Helpful links

The post My Week in Beagle #5 appeared first on BeagleBoard.

This Week in Beagle #4

✇BeagleBoard
By: Ayush Singh

Hello everyone. Another light week here. Let’s go over everything.

BeagleBoard Rust Imager

Continuing the trend from previous weeks, many developments took place in BeagleBoard Rust Imager.

MacOS

Thanks to help from Zain, BeagleBoard Rust Imager SD card flashing finally works on MacOS. With this, it is now possible to flash Linux images to an SD card on MacOS.

Any developers requiring similar functionality should look at the PR. Here are the steps in brief:

  1. Unmount the sd card using diskutil.
  2. Create pipes using std::os::unix::net::UnixStream::pair().
  3. Create a MacOS Authorization external form using security_framework::authorization.
  4. Launch authopen with the -extauth argument using std::process::Command with the send pipe as stdout.
  5. Send the MacOS authorization external form to the process stdin.
  6. Read the SCM_RIGHTS control message from the receive pipe and get the file descriptor.

Sd card formatting

SD card formatting is now supported on both Windows and Linux. MacOS support is still pending. This is useful for making the bootable SD cards usable again.

Offline support

Offline use of BeagleBoard Rust imager for all supported boards is now possible. The base configuration now includes definitions for all boards.

MicroBlocks

Since MicroBlocks IDE v2 has been released, there has been a new release of MicroBlocks stable firmware. You can grab the latest firmware for BeagleBoard Freedom from here.

GPIO Nexus Node Schema

While working on MikroBUS patches, I encountered devicetree nexus nodes. It allows the ability to create proxy GPIO controller thereby providing a stable numbering scheme for GPIO pins on MikroBUS socket.

To allow use in the Linux kernel, I created a PR to add the dt schema to the upstream repository. It has now been merged.

Dynamic alias in Linux devicetree

Currently, adding/removing/updating /aliases is not supported in the upstream Linux kernel. This means overlays cannot rely on using /aliases, which are much more powerful than existing /__symbols__. In my patch series to add support for phandles in /__symbols__, it was brought up that it might be better to switch to using /aliases instead of trying to add more to /__symbols__.

So I have created a new patch series based on the original patch series by Geert Uytterhoeven in 2015.

Ending Thoughts

This was it for this week. Hopefully, this helps bring transparency regarding where the development efforts are concentrated, and how the community can help. Look forward to next update.

Helpful links

The post This Week in Beagle #4 appeared first on BeagleBoard.

This Week in Beagle #3

✇BeagleBoard
By: Ayush Singh

Hello everyone. Another light week here. Let’s go over everything.

BeaglePlay PWM Patch

A while ago, I discovered that the MikroBUS PWM pin was not enabled in the upstream devicetree for BeaglePlay. So I created a patch to enable PWM and it was finally merged last week.

BeagleConnect Freedom Debugging

Continuing the work from last week, I was able to load Zephyr firmware that exhibited the stalling behavior. However, I still haven’t been able to pinpoint the exact cause. You can follow the discussion in Ti E2E

I have created a minimal example to reproduce the problem.

BeagleBoard Rust Imager

There has been some interest in making the Rust flasher the official flasher. To achieve that, there has been a lot of development towards v1.0.0.

MacOS dmg support

Thanks to help from Zain, I was able to create MacOS dmg in CI. While most of the flashing functionality does not work on MacOS yet, having easy experimental CI builds should help development to at least ensure everything builds.

Make bb-imager-rs Ready for crates.io

While exploring ways to create a Debian package, I stumbled across debcargo, which is the official way to package Rust applications for Debian. Since it can potentially allow official packages in the future, I decided to prefer it over cargo-deb. However, since debcargo builds the package from crates.io, I needed to cleanup the out of tree patches for rs-drivelist and bin_file. So, I moved the unmerged/unreleased code into bb-imager itself for now.

I still need to set up CI to push to crates.io automatically, but I am a bit unsure regarding how to handle the API key securely.

Sd Card Formatting Support

I have added support for SD card formatting since it is helpful for an imaging utility. However, it does not work on Windows yet.

Performance Enhancements and Code improvements

Here is the list of minor improvements that occurred during the week:

  • More responsive UI
  • Make the default window size smaller
  • Better handling of big os image lists.
  • Code improvements to make contribution easier.

Ending Thoughts

This was it for this week. Hopefully, this helps bring transparency regarding where the development efforts are concentrated, and how the community can help. Look forward to next update.

Helpful links

The post This Week in Beagle #3 appeared first on BeagleBoard.

This Week in Beagle #2

✇BeagleBoard
By: Ayush Singh

Hello everyone. This week mostly involved a lot of chasing stuff around (sometimes in vain), so while there was not much headline work, this post might end up a bit longer than usual. Let’s get started without delay.

BeagleConnect Freedom Adventures

I started the week by trying to add IEEE802154 subg socket support in MicroPython for BeagleConnect Freedom. However, I quickly learned that it would not be simple. For some reason, BeagleConnect Freedom would completely lock up after starting.

Initially, I thought it might be a MicroPython issue, so I tried tracking down where the freeze happened. This, however, led to a dead end since, for some reason, the program would not be able to read from the UART console. While doing this, I also remembered a similar issue I encountered while working on BeagleConnect Freedom rc car demo. At the time, I fixed it by just removing unused config items like ADC and PWM from config, but forgot about it after the OOSC conference.

After some experimenting with PWM, ADC, and IEEE802154 subg radio, I figured out that the problem is reproducible in other Zephyr samples like echo_cliet, etc. For some reason, if both PWM pins (MB1 PWM and MB2 PWM) are enabled alongside the subg radio, everything freezes. If one or both of the PWM are disabled, everything works fine. This seems to be an issue with timers but it needs further investigation.

I have created a Zephyr issue and a Ti E2E question for the same.

Code Composer Studio Theia Adventures

With the MicroPython issue and a bricked BeagleConnect Freedom, I thought it is a good time to setup and learn Ti’s Code Composer Studio.

I use Fedora Sway Atomic as my daily driver, and thus mostly rely on flatpaks or podman containers. However, running Code Composer Studio inside a podman container (created using toolbox) was not a great experience for me. It would randomly stutter (maybe a hardware acceleration problem?) and freeze. Additionally, while udev can make it almost painless to handle device permissions, it can occasionally cause hiccups with flashing. In fact, one of the primary reasons I switched to neovim was that my emacs GUI kept having weird performance problems inside the container.

So, I finally went ahead and installed CCS Theia on my base system. The install procedure is a bit weird since there is no rpm or deb package. Instead, there is an installer which installs everything in $HOME/ti folder. It also creates an uninstall, which seems to work. All in all, while I prefer a flatpack or app image, it wasn’t too bad.

I hit a snag quite early on when I was unable to flash the cc1352p1 on my launchpad. I tried various things and opened a Ti E2E question for the same. However, the solution turned out to be quite weird. I was not saving my workspace since, well, nothing was working anyway, and CCS Theia would open the unsaved workspace. But everything magically worked once I saved my workspace because I was tired of the dialog on exit. Not really sure why.

Once I could flash the launchpad, I tried using the xds110 in launchpad with my BeagleConnect Freedom. I was able to flash a simple blinky on it and even set up breakpoints.

Now, I need to figure out how to use openocd and add instructions in Beagle docs and Zephyr docs for the same.

KUnit Adventures

I have been working on kernel patches that require writing some unit tests. So I was trying to get KUnit to work. However, kunit run kept on failing for some reason, even with the default config. The output was not very clear either. However, after following some debugging instructions, I found out that I could not execute the user mode kernel from inside the podman container. I have created an issue in Fedora toolbox regarding the same.

MicroPython

I have added MicroPython support for BeaglePlay cc1352p7 in my draft PR. It supports IEEE802154 subg sockets and also helped me ensure that MicroPython networking should work fine on BeagleConnect Freedom as well once the timer issue is resolved.

Since BeaglePlay cc1352p7 Zephyr support was merged after the 3.7.0 release, the MicroPython support will continue to live in the draft PR until MicroPython supports a newer Zephyr version.

Zephyr

Zephyr support for BeagleBoard boards continues to improve. We will continue to work to make Beagle one of the best-supported platforms for Zephyr development.

BeagleBone AI-64

Thanks to the work by Andrew Davis, Zephyr support for R5 cores in BeagleBone AI64 was merged this week. Here is the Zephyr page for BeagleBone AI 54. This adds one more board to the growing list of BeagleBoard boards that support Zephyr.

BeagleY-AI

A PR for Zephyr support was opened by Andrew Davis after BBAI-64 support was merged. Anyone interested should feel free to try it out. Hopefully, it can get merged upstream soon.

BeagleBoard Imager Rust Updates

While working on BeagleY-AI, I found a bug in the sha256 handling of the Rust-based imager while translating the old bb-imager config. So, I have created release 0.0.2 for the imager. I probably should implement changelogs before the next release.

Ending Thoughts

This was it for this week. Hopefully, this helps bring transparency regarding where the development efforts are concentrated, and how the community can help. Look forward to next update.

Helpful links

The post This Week in Beagle #2 appeared first on BeagleBoard.

This week in Beagle #1 by Ayush Singh

✇BeagleBoard
By: Ayush Singh

Hello everyone. This is the start of a new blog series to keep the community in the loop regarding the work done by BeagleBoard.org members and the community. Hopefully, I can stick to the schedule.

MicroPython

Initial BeagleConnect Freedom Support

While we have had MicroPython firmware for BeagleConnect Freedom in the past, the work was out of tree. This made maintenance and collaboration hard to do. There were a few reasons for having the support out of tree:

1. Zephyr support for BeagleConnect Freedom was primarily out of tree, with just basic support in mainline.
2. MicroPython only supported Zephyr v3.1.0

Due to my work, BeagleConnect Freedom supports almost everything in mainline Zephyr. Additionally, due to the fantastic work by Maureen Helm, MicroPython now supports Zephyr v3.7.0. So, it seemed like a good time to have support for BeagleConnect Freedom in mainline MicroPython. Here is the link to the merged PR. It does not contain more advanced features like ADC and PWM right now, but those are also on the way.

PWM support for Zephyr Port

While working on adding PWM support for BeagleConnect Freedom in MicroPython, I discovered that the Zephyr port of MicroPython did not support PWM. So, I ended up working on adding PWM support. Here is the PR.

MicroBlocks v2.0

MicroBlocks is a blocks programming language for physical computing inspired by Scratch. BeagleConnect Freedom has had good support for MicroBlocks, as outlined in a prior post.

Recently, MicroBlocks v2.0 was released in pilot and thankfully, BeagleConnect Freedom works with the newest firmware perfectly, without any real change in the Zephyr port.

Arduino Module for Zephyr

Due to the recent cleanup of the defaults in the device tree of BeagleConnect Freedom, ADC and PWM are supported without any overlays. So just a simple cleanup of Arduino module overlay. Here is the PR.

BeagleBoard Rust Imager

The v0.0.1 release of the BeagleBoard Rust imager took place last week. It has the following features:

  1. Platforms:
    1. Linux
      1. GUI Appimage
      2. CLI binary
    2. Windows
      1. GUI Portable exe
      2. CLI binary
    3. macOS
      1. CLI binary
  2. Boards
    1. Generic Linux (BeaglePlay, Beagle AI64, BeagleY-AI,  BeagleV-Fire, BeagleBone Black, etc)
    2. BeagleConnect Freedom
    3. BeagleConnect Freedom MSP430

It is basically at feature parity with the original BeagleBoard Imager based on Raspberry Pi and supports additional boards like BeagleConnect Freedom. Here is the release page.

Ending Thoughts

This was it for this week. Hopefully, this helps bring transparency regarding where the development efforts are concentrated, and how the community can help. Look forward to next update.

The post This week in Beagle #1 by Ayush Singh appeared first on BeagleBoard.

❌