Debian Minimal (non-graphical) image for PocketBeagle 2 based on TI AM6232 processor
Remember to set your user password in the sysconf.txt file in the fat32 partition before you boot (or use bb-imager and set it in that GUI).
The post PocketBeagle2 Debian 12.9 2025-01-15 Minimal appeared first on BeagleBoard.
Hello everyone. A typical week for development. Let’s go over everything.
Pocketbeagle2 uses MSPM0 as both EEPROM and ADC. The EEPROM is used to store board-specific information in all BeagleBoard boards for easier debugging and differentiation of different revisions.
While the pb2_mspm0 driver supports updating firmware, it isn’t suitable to be used directly by new people:
To solve this, I have added pb2_mspm0 support directly to bb-imager-cli. There is also a flag to control if EEPROM contents should be preserved (since it is possible to flash firmware other than the default one). Additionally, since bb-imager-rs supports Ti-TXT and iHex by default, we get that support for free.
I am still trying to figure out how to add support to the GUI since the flashing requires access to sysfs entries, which are owned by root (and probably should stay that way). I think I am supposed to use polkit, but not completely sure.
I have added instructions regarding Contribution and Packaging to hopefully make it easier for newcomers to get started. It also helped be document a lot of stuff that even I forget, so it should prove useful.
For pocketbeagle2 testing, I wanted to be able to cross-compile from my main machine without needing to tinker too much. I had used cross in the past, but it turns out that the container cross uses by default is based on Ubuntu 20.04, which contains libssl1. Pocketbeagle2 images have libssl3, which means that I could not use the default images for cross-compiling.
I have added custom image dockerfiles, so cross-compiling should be as simple as setting RUST_BUILDER=cross and running a make recipe.
Note: cross compiling is only supported for the following targets right now:
Windows should support can probably be added with a custom dockerfile (or the default cross windows container might work), but I do not need it much, so haven’t really tried adding it.
A few weeks ago, Herve Codina sent patches to the kernel mailing list for supporting export-symbols as another possible way to support addon board overlays. Since adding support for path references to overlays ended up being a dead end (see here), I have starting working on export-symbols based approach for mikroBUS.
As a part of that effort, I am working on adding export-symbols support to the base devicetree compiler, to hopefully make it part of devicetree specification instead of just a Linux specific thing. That way, it should be possible to support the same addon-board overlays in Zephyr in the future.
I started work with adding support to the base devicetree compiler. The patch series does not contain tests right now since this is more of an RFC for now.
Similarly, I also sent the patch series for support in fdtoverlay. The tests will be added to future versions of the patch.
As discussed in the original patch series, to make use with fdtoverlay possible, we need to add a way to pass the target path to fdtoverlay, which is not supported right now. I will try to work on it this week. Hopefully, addon board support will be merged before 2026.
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 #10 appeared first on BeagleBoard.
Happy New Year, everyone! 2024 was a fantastic year for my coding journey, and I’m thrilled to carry that energy into 2025.
Let’s jump into the weekly updates and kick off another exciting year of coding adventures.
A lot of work went into the BeagleBoard Rust Imager this week. I still haven’t figured out Macos completely, but at least other platforms are moving along well. At this point, I will probably release v1.0 without MacOS support since there is not much I can do about it.
Most of the past work concentrated on improving the GUI and making it as user-friendly as possible. However, as a terminal enjoyer, I prefer to use the CLI when possible. In lieu of that, I spent most of the past week bringing up the CLI to the point of being great to use, at least on Linux. Let us now go over some of the work:
The GUI has an option to perform some customization (e.g., setting user name and password, setting wifi ssid and password, etc.) after flashing the SD card. This ability in CLI would allow much easier automation when one needs to flash multiple devices. So, the CLI is now able to perform all the customization options available in the GUI.
Since it might be useful to be able to flash OS images from the internet, I ended up adding an option to flash remote OS images. I am a bit unsure regarding this one since one could just use wget, but it might end up being useful once I add an option to browse remote images using the default distros.json that the GUI uses.
One area that saw massive improvements is the help messages for the CLI (along with all the subcommands). It should be fairly simple for people to understand how to use the CLI now.
The CLI now supports generating shell completions at both runtime and compile-time. I am using clap_complete to achieve this. The compile-time generation is done using xtask instead of build.rs, since it allows me to generate the completion on demand.
I am also generating manpage(s) for the CLI and all of its subcommands at compile time using clap_mangen. Similar to shell completion, I am using xtask for this.
While working on shell completion and manpage support, I came across cargo xtask spec, which allows adding free-form automation to a Rust project. It’s pretty neat since it does not need anything extra (other than cargo and rustc) and gives the power of full-fat Rust. It’s especially nice for cases like shell completion and manpage generation since they need to interact with Rust code and cannot be done with just Makefile recipe.
My current policy will be to use xtask when I need something that requires bash scripting but will stick to Makefile when just calling POSIX utilities is sufficient for the job. I have seen projects use xtask for CI, but I still prefer Makefile for that kind of functionality.
Here are some showcases for the CLI.
Login
❯ bb-imager-cli --help
A streamlined tool for creating, flashing, and managing OS images for BeagleBoard devices.
Usage: bb-imager-cli [OPTIONS] <COMMAND>
Commands:
flash Command to flash an image to a specific destination
list-destinations Command to list available destinations for flashing based on the selected target
format Command to format SD Card
generate-completion Command to generate shell completion
help Print this message or the help of the given subcommand(s)
Options:
--quiet Suppress standard output messages for a quieter experience
-h, --help Print help
-V, --version Print version
❯ bb-imager-cli flash sd --help
Flash an SD card with customizable settings for BeagleBoard devices
Usage: bb-imager-cli flash <DST> sd [OPTIONS]
Options:
--no-verify Disable checksum verification post-flash
--hostname <HOSTNAME> Set a custom hostname for the device (e.g., "beaglebone")
--timezone <TIMEZONE> Set the timezone for the device (e.g., "America/New_York")
--keymap <KEYMAP> Set the keyboard layout/keymap (e.g., "us" for the US layout)
--user-name <USER_NAME> Set a username for the default user. Requires `user_password`.
Required to enter GUI session due to regulatory requirements.
--user-password <USER_PASSWORD> Set a password for the default user. Requires `user_name`.
Required to enter GUI session due to regulatory requirements.
--wifi-ssid <WIFI_SSID> Configure a Wi-Fi SSID for network access. Requires `wifi_password`
--wifi-password <WIFI_PASSWORD> Set the password for the specified Wi-Fi SSID. Requires `wifi_ssid`
-h, --help Print help
❯ bb-imager-cli flash --image-remote $IMG_URL --image-sha256 $IMG_SHA256 /dev/ttyACM0 bcf
[1] Preparing
[2] Verifying [█████████████████████████████████████████████████████████████████████████████████████████████████████████████] [100 %]
[3] Flashing [█████████████████████████████████████████████████████████████████████████████████████████████████████████████] [100 %]
[4] Verifying
❯ bb-imager-cli --quite flash $DESTINATION $IMG_PATH /dev/ttyACM0 bcf
While putting the GUI alongside the Raspberry Pi Imager, I observed that my GUI and its elements, like buttons, were a lot bigger. After some discussion, I ended up deciding to match the rpi-imager size. So, the default window size is now 680×450, with the buttons and other UI elements scaled down accordingly.
I also added some rounded corners since they look nicer in the scaled-down UI. The buttons and text are still a bit bigger than the RPI-imager, but since it fits fine, I am keeping it like this.
I have been working on utilizing Gitlab issues as much as possible in the bb-imager-rs to make it easier for anyone wishing to start contributing. Hopefully, I can get some new contributors this way.
That is all for the week. Hopefully, 2025 will be a good year for me and BeagleBoard.org. Look forward to next update.
The post This Week in Beagle #9 appeared first on BeagleBoard.
Hello everyone. I have been traveling for the last few weeks due to some family functions. Additionally, I was primarily working on Pocketbeagle2 stuff, which wasn’t public yet, so I also lacked content. Now that Pocketbeagle2 has been announced, I can start talking about it. So, let’s get to it.
In Pocketbeagle2, instead of using dedicated EEPROM and ADC, we are using MSPM0L1105 with specilized firmware that acts as EEPROM and ADC.
While it is possible to use a userspace flasher, it is much easier to perform firmware updates with an upstream driver. Additionally, it also allows doing some custom pinmux and overlay stuff, which might be required due to a problem with the nRST line.
While the MSPM0L1105 is intended to be used as EEPROM and ADC by default, it can be used as a dedicated co-processor for IO and communicate over I2C or SPI. I will also try to add Zephyr support in the future.
The driver is currently in my kernel tree.
A while ago, I found an issue with BeagleConnect Zephyr support, where everything freezes if both PWM and SUBg are enabled at the same time. Thanks to help from Arthur, I was able to confirm that this does not happen in Ti-RTOS and is thus a problem with Zephyr implementation. However, I was not able to find the root cause, even with JTAG debugging. The complete discussion can be found in e2e.
Fast forward to last week, and I thought I should try tackling it again before starting work on Arduino support using LLEXT. One of the possibilities I came up with was that it might be a bug in the version of simplelink SDK that was being used in hal_ti. The SDK being used currently is 4.40.04.04, which is quite old at this point. Additionally, I wanted to use the latest SDK before attempting to tackle Bluetooth again.
While working on it, I realized that it is currently not possible to automate SDK updates since we need to make some modifications manually. In the end, it turned out that the SDK version was not the cause of the freeze, but it helped me figure out the real cause.
Hopefully, I can figure out a more sustainable way moving forward, but I just went with the manual route for now.
It also seems like GPIO APIs have completely changed, and I had to fix some stuff in the Zephyr GPIO driver. Here are the open PRs: hal_ti and zephyr.
As discussed above, I was finally able to pinpoint the cause of the freeze. It turns out that the Zephyr power management was at fault. Both the PWM driver and RF core driverlib can put and release constraints on the suspend state of cc1352p7. However, at least the PWM code would release the constraint without checking if PWM placed the constraint in the first place.
I have created an initial PR to fix the problem by ensuring that PWM keeps track of the suspend constraint. This ensures that PWM does not cause the processor to go to suspend even if it has been disabled by subg code.
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 #8 appeared first on BeagleBoard.
“This Week in Beagle” is a weekly blog series by BeagleBoard.org’s own Ayush Singh that highlights significant contributions he and others are making in the open-source community.
In November/December, Ayush and other community members teamed up on advances in:
Select the date above to view Ayush’s weekly progress or visit www.beagleboard.org/blog to see all of his recent contributions.
The post This Week in Beagle ROUND-UP: November/December ’24 appeared first on BeagleBoard.
The BeagleCast 2024 Holiday Special discusses developments in BeagleY-AI, community growth, and future projects for 2025—including the imminent release of PocketBeagle 2.
Episode Highlights
2024 marked as the year of AI with community-driven projects. BeagleY-AI’s promising mainline support. Upcoming Pocket Beagle 2 features improved performance and connectivity. Exciting developments in Zephyr OS support for Beagle products. Emphasis on documentation and mentorship for GSoC 2025. Discord community surpassed 2,000 members, showcasing engagement. Appreciation for community contributions and collaborations.The post BeagleCast: 2024 Holiday Special appeared first on BeagleBoard.
It’s hard to believe 2024 is nearly over. But what a year it has been here at BeagleBoard.org Foundation.
We saw the release of BeagleY-AI — our low-cost, open-source, and community-supported development platform designed for developers, hobbyists, and anyone looking for a reliable single-board computer to build solutions to a wide range of computing, embedded systems, graphical interface and AI applications.
We sponsored three successful Google Summer of Code (GSoC) participants, where our mentees worked on free and open-source coding projects. These included:
Of course, these weren’t the only exciting projects and contributions we participated in. We generated a lot of interest in our weekly Zephyr hacking sessions. We also worked on advancing other open-source technologies like Microblocks, Greybus, Micropython on Zephyr, and dynamic device tree overlays in Linux, where we explored new ways to improve the experience of these various development solutions, especially on BeagleBoard.org platforms.
As 2024 draws to a close, we wanted to take a moment to give thanks for several important milestones BeagleBoard.org celebrated this year.
It goes without saying, technology is only as good as its users. This is something all developers can relate to.
That’s why we wanted to show gratitude to the open-source movement, new partnerships and our growing community.
Here at BeagleBoard, we firmly believe in open-source technology that makes easy things easier and hard things possible.
This year alone, we saw many contributions to the open-source ecosystem that live up to that aspiration by democratizing general-purpose, real-time, and AI computing for everyone. In addition to the open-source BeagleY-AI platform, contributions to open projects like Zephyr, toolchains like PlatformIO, and build environments such as Yocto helped improve access to electronics education and productization.
BeagleBoard continued to grow relationships in 2024 with companies like Balena, Bela, Bootlin, MikroElektronika, Mender.io, and more.
These relationships play an important role in enabling design freedom and flexibility across tech stacks for students, makers, and commercial projects. They also align with our goal of creating solutions that encourage people to try new things by eliminating barriers to the development process.
It’s no secret the BeagleBoard community is one of the most vibrant in the ecosystem. With nearly 60,000 users across the BeagleBoard.org forum, Discord, and our mailing list. In 2024 alone, we saw our Discord surpass 2,000 members.
We’re incredibly lucky to have such a dedicated community of users who actively help drive the direction of BeagleBoard through their participation, requests, and contributions. Hard work and dedication from community members like you make working at the Foundation so rewarding.
We’re beyond excited for what the future holds as our community grows.
For BeagleBoard.org Foundation, showing thanks in 2024 means appreciating open-source technology, acknowledging partners who continue to believe in our vision, and, most importantly, celebrating our community of passionate developers who support and encourage each other and us every step of the way.
We are ecstatic about everything we accomplished together in 2024 and will continue to give back as much as we can to make computing better and more accessible for all.
– The BeagleBoard Team
The post Giving Thanks for Open Source, Partnerships & Community in 2024 appeared first on BeagleBoard.
GPIO stands for General-Purpose Input/Output. It’s a set of programmable pins that you can use to connect and control various electronic components.
You can set each pin to either read signals (input) from things like buttons and sensors or send signals (output) to things like LEDs and motors. This lets you interact with and control the physical world using code!
A great resource for understanding pin numbering can be found at pinout.beagley.ai
…
import gpiod import time gpio14 = gpiod.find_line('GPIO14') gpio14.request(consumer='beagle', type=gpiod.LINE_REQ_DIR_OUT, default_val=0) while True: gpio14.set_value(1) time.sleep(1) gpio14.set_value(0) time.sleep(1) ...
See more at https://docs.beagle.cc/boards/beagley/ai/demos/beagley-ai-using-gpio.html
The post Using GPIO on BeagleY-AI appeared first on BeagleBoard.
I have shared all the GCODE files and 3mf files on Printables along with all the required information. I hope you will enjoy
Printables Link: https://www.printables.com/model/1003829-beaglebone-black-enclosure
The post 3D printed case for Beaglebone Black appeared first on BeagleBoard.
Hello everyone. I was busy with the Linux kernel for most of the week. Let’s go over everything.
MicroBlocks dev branch recently broke the MicroBlocks Zephyr Port. I sent a patch to the Discord channel, and it has been fixed.
A lot of work this week was focused on the device tree compiler. I have been working on adding support for path references in devicetree overlays. In the initial patch, some parts of the initial patch series can be sent as independent patches. So last week mostly involved getting those merged.
Previously, all the setprop variants calculated length of property length from strlen. However, devicetree __fixups__ contains information regarding the position of a property to resolve, and thus cannot use these normal variants. Additionally, it is not allowed to use heap memory in many places in the devicetree compiler and related tools, and thus, there was a need for setprop_namelen_* variants of functions similar to how these exist for getprop_namelen_*.
The patch series has been merged now.
While working on the devicetree compiler code, I was using the clang-format config from the Linux kernel. As suggested by David Gibson, I sent a patch to add the clang-format config which has now been merged.
Since the related patch for setprop namelen variants has been merged, I have been working on version 2 of the path reference support patch. Since it is not allowed to use dynamic allocation, I have been able to get things working with adjusting offsets while growing. I still need to fix some tests and add new ones, but I should be able to post the patches this week.
As per the suggestion in the issue, I have been experimenting with moving around the configuration screen flow. A prototype can be found here. I have not yet finalized whether this should be merged.
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 #7 appeared first on BeagleBoard.
Hello everyone. Another light week here. Let’s go over everything.
While hacking on my BeagleY-AI, I found that my HP SD card did not work with BeagleY-AI for some reason. On digging a bit further, some SD cards were not working on BeagleY-AI due to some issues with signal voltage switching on the am62x platform. This has now been fixed, as seen in the following patch series. By switching out the Linux kernel to mainline, I was able to get the HP SD card to work. So, the SD card compatibility of BeagleY-AI will improve soon.
BeagleBoard Rust imager got lots of love this week.
As pointed out by Jason here, the BeagleBoard Rust imager appimage is not usable with AppimageLauncher. The issue seems to be that appimagetool uses ZSTD compression now, while AppimageLauncher does not support it yet. Moreover, it seems like AppimageLauncher makes the appimage unusable. For now, the recommendation is to either remove AppimageLauncher or at least deactivate it for the BeagleBoard Rust imager.
More information regarding the upstream issue can be found here.
While the SD card flashing worked, it was much slower than the original bb-imager. After some tinkering with the buffer size while flashing and using parallel decompression of xz images, SD card flashing should be much faster (flashing time decreases by 57%).
It is still a bit slower than the original bb-imager (about 1 min), but it seems related to the internals of QFile, so that would be much more work than just a day.
BeagleBoard Rust imager now builds Debian packages in CI using cargo-deb. While the goal is to eventually have an upstream package using debcargo, there is not much point until bb-imager-rs hits v1.0.0. Additionally, since debcargo only seems to support building stuff already present in cartes.io, it does not seem suitable for experimental builds (although I could be wrong about that).
Builds from the latest main branch are now pushed to Package Registry rather than just being stored as build artifacts. This makes grabbing the latest development version of bb-imager-rs much simpler.
Note: Only the most recent build is kept around.
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 #6 appeared first on BeagleBoard.
Hello everyone. I was busy with the Linux kernel for most of the week. Let’s go over everything.
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 allows references in two contexts:
foo = <&bar>;
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.
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 My Week in Beagle #5 appeared first on BeagleBoard.
Hello everyone. Another light week here. Let’s go over everything.
Continuing the trend from previous weeks, many developments took place in BeagleBoard Rust Imager.
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:
diskutil.std::os::unix::net::UnixStream::pair().security_framework::authorization.authopen with the -extauth argument using std::process::Command with the send pipe as stdout.SCM_RIGHTS control message from the receive pipe and get the file descriptor.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 use of BeagleBoard Rust imager for all supported boards is now possible. The base configuration now includes definitions for all boards.
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.
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.
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.
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 #4 appeared first on BeagleBoard.
Stay tuned!
The post PocketBeagle 2 appeared first on BeagleBoard.
Hello everyone. Another light week here. Let’s go over everything.
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.
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.
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.
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.
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.
I have added support for SD card formatting since it is helpful for an imaging utility. However, it does not work on Windows yet.
Here is the list of minor improvements that occurred during the week:
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 #3 appeared first on BeagleBoard.
Stay tuned!
For evaluation, please try BeagleMod BM3301-1313 on BeagleY-AI
The post BeagleMod CC33 appeared first on BeagleBoard.
Stay tuned!
The post BeagleMod AM62 appeared first on BeagleBoard.
BeagleMod is a family of solder-down modules suited for embedding into your project.
The post BeagleMod appeared first on BeagleBoard.
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.
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.
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.
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.
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 support for BeagleBoard boards continues to improve. We will continue to work to make Beagle one of the best-supported platforms for Zephyr development.
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.
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.
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.
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 #2 appeared first on BeagleBoard.
