Hello everyone. Another typical week. Let’s go over everything.

BeagleBoard Image Builder

After much deliberation last week, I decided to go ahead with trying to use debos for image generation. I was able to create debos recipes for BeagleY-AI and PocketBeagle 2. However, the image generated by debos does not seem to boot on either board. More specifically, it does not seem like the soc is able to find the bootloader (u-boot) present in the BOOT partition.

I did cross-check everything with the current images, and the partitions seem to be in order. So not sure what is going on here. I also went through the debos source code to see how it was creating the partitions, but recreating it in normal shell scripts does seem to work as expected. I also tried generating empty images using debos and copying the boot partition to the appropriate partition, but still could not get it to work.

I have created an issue regarding this, with some scripts that generate the image properly. Let’s see if it can be resolved soon.

PocketBeagle 2 Examples

Some work also went into cleaning up the current examples for PocketBeagle 2. I will be getting my PocketBeagle 2 and TechLab Cape delivered by the end of the week, so hopefully, the examples will be greatly expanded in the upcoming weeks.

Refactor Dependencies

The examples were pulling some unnecessary dependencies, so I removed most of them. Now, there are only 6 dependencies, which is always nice.

I have switched to gpiod for GPIO handling. This is because I went through the source code of both gpiod and gpio-cdev, and felt that gpiod was superior. Additionally, gpiod supports both v1 and v2 of GPIO Character Device Userspace API, while gpio-cdev only supports v1.

I can always write any shim that might be required for interop with embedded_hal myself.

Add blinky ioctl example

I have also added a blinky example, that directly uses GPIO Character Device Userspace API instead of gpiod library. This should help anyone curious peek behind the curtain and get an idea of how the GPIO libraries work behind the scenes.

I am also thinking of creating a blinky example that does not have any dependencies, although I am a bit unsure if it should be another example, or just do that in this example.

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

• BeagleBoard
• Pocketbeagle 2
• PocketBeagle 2 Examples
• debos recipies

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

Debian Minimal (non-graphical) image for PocketBeagle 2 based on TI AM6232 processor

Remember to set your user password in the sysconf.txt file located in the fat32 partition before you boot (or use bb-imager and set it in that gui).

• Kernel: v6.12.9-ti-arm64-r20
• U-Boot: v2025.04-rc2-pocketbeagle2
• VSCode: v4.96.4
• Node-RED: v4.0.2

Changes:
u-boot: v2025.04-rc2
6.12.9-ti-arm64-r20 fixes some of the lockups seen on 6.12.9-ti-arm64-r19

The post PocketBeagle 2 Debian 12.9 2025-02-13 Minimal appeared first on BeagleBoard.

Hello everyone. I ended up experimenting more than getting results, so not much to write. Let’s go over everything.

PocketBeagle 2 Examples

Continuing the work from last week, more PocketBeagle 2 examples have been added.

Feel free to create issues regarding the examples you would like to be added.

Button

Simple example to detect button presses. Uses Pin P1_20 by default.

Usage

debian@pocketbeagle2:~/vsx-examples/PocketBeagle2$ cargo run -p button
   Compiling button v0.1.0 (/home/debian/vsx-examples/PocketBeagle2/button)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.05s
     Running `target/debug/button`
Chip: gpiochip2 [600000.gpio] (92 lines), offset: 50
Button pressed
Button pressed
Button pressed
Button pressed

Fade

Simple example to fade an LED in and out using PWM. Also contains abstractions to use PWM using sysfs.

Uses P1.36. In case of TechLab Cape, this PIN is connected to RGB.B

Usage

debian@pocketbeagle2:~/vsx-examples/PocketBeagle2$ cargo run -p fade -r
   Compiling fade v0.1.0 (/home/debian/vsx-examples/PocketBeagle2/fade)
    Finished `release` profile [optimized] target(s) in 3.85s
     Running `target/release/fade`

BeagleBoard Image Builder

Currently, the image build process for all BeagleBoard images involves a collection of scripts singlehandedly maintained by Robert Nelson. Thanks to his amazing work on both handling the management of openbeagle runners and image building, things have been working relatively well.

However, this also means that all the burden of pushing and maintaining new images falls on one person. Additionally, the images cannot currently be built in openbeagle, which limits the experimentation and having very special purpose images.

To hopefully improve the current situation, I have been working on trying to get image build working on openbeagle CI. I initially started with trying to get debootstrap directly working in CI, but while I could get it somewhat working (defining working very loosely here), it failed in CI.

Currently, I have 2 possible solutions I am exploring:

1. debos: Seems quite promising. Has good performance, and should work fine in CI. Additionally, it also can work with just user-mode-linux, so quite portable. Moreover, it already has a recipe system pretty similar to what I want in the final solution.
2. Using docker: This was mostly inspired from yasib. I was able to build rootfs for the most part, but there were quite a few warnings for systemlevel packages like systemd.

I am still experimenting with both of the above approaches. However, I have started leaning more towards debos. It can have much better performance than docker in docker, and already has been tested quite a bit. Additionally, I can always add support for 2nd approach to debos in the future.

Hopefully, I will have working images by next week.

Optimize linux-embedded-hal dependencies

I have been using linux-embedded-hal in some of the PocketBeagle 2 GPIO examples. When working with it, I observed that it was pulling some unnecessary dependencies even when default-features were disabled. I created a PR to fix it, which has now been merged.

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

• BeagleBoard
• Pocketbeagle 2
• PocketBeagle 2 Examples

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

Debian Minimal (non-graphical) image for PocketBeagle 2 based on TI AM6232 processor

Remember to set your user password in the sysconf.txt file located in the fat32 partition before you boot (or use bb-imager and set it in that gui).

• Kernel: v6.12.9-ti-arm64-r19
• U-Boot: v2025.01-pocketbeagle2
• VSCode: v4.96.4
• Node-RED: v4.0.2

Fixes: 1Ghz Opp (before limited to 800Mhz)…

The post PocketBeagle 2 Debian 12.9 2025-02-07 Minimal appeared first on BeagleBoard.

Hello everyone. Since PocketBeagle 2 has launched, most of the development was focused on it. Let’s go over everything.

Enable Greybus BeaglePlay driver in defconfig

As per suggestion of Nishanth Menon, I have added gb_beagleplay to the defconfig. Here is the latest version of the patch.

Export Symbols RFC

As alluded to in my prior posts, I have been working on using export-symbols in devicetree to add support for add-on connectors such as MikroBUS. This was first proposed by Herve Codina in the following Linux kernel patches. Since then, I have sent patches to add support to devicetree compiler and fdtoverlay.

The overall goal is to make export-symbols part of devicetree specification instead of just a Linux specific extension. This is to allow sharing of add-on board overlays with ZephyrRTOS, which has boards like BeagleConnect Freedom with support for MikroBUS.

To that end, I have sent an RFC in the devicetree specification mailing list to see if anyone has any objections/flaws to point out. I will be sending a patch adding the node to the specification in a week or 2, if there are no objections.

PocketBeagle 2

PocketBeagle 2 is now available for purchase. While, everything is mostly working now, I have been working on adding a few things to just make the support as good as possible.

Debug Port

In the early phases of development, most people were using PocketBeagle® TechLab with PocketBeagle 2, and thus using the UART exposed by it. However, PocketBeagle 2 has a debug UART (compatible with Raspberry Pi Debug Probe) on board.

There were some issues to get U-Boot working with this UART, but other than U-Boot R5 logs, everything is redirected to use the Debug Port. We are actively working on getting R5 to also use the debug port, but it should not affect general usage, since the boot selection menu is shown by A53 core.

Examples

In a recent discussion, it was also decided to add examples for beginners to get started quickly. Initially, I was going to use Python, but given that Beagle Boards seem to attract a lot of people in Kernel and U-Boot space, it was decided that I should go ahead with writing examples in Rust.

With Rust support in Linux kernel finally reaching a good enough state, this means the same language can be used for both userspace IoT projects and Kernel space drivers.

Rust is also quite popular nowadays, so it might help attract new potential contributors. The examples can be found here. Hopefully, they will start being shipped in default images, and will be accessible with the Theia local Theia editor.

Feel free to create issues regarding the examples you would like to be added.

Hello Beagle

Simple example to test that Rust has been set up correctly.

Usage

debian@pocketbeagle2:~/vsx-examples/PocketBeagle2$ cargo run -p hello_beagle
   Compiling hello_beagle v0.1.0 (/home/debian/vsx-examples/PocketBeagle2/hello_beagle)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 5.64s
     Running `target/debug/hello_beagle`
Hello, World! From PocketBeagle2

EEPROM

Read and parse EEPROM contents in Rust.

Usage

debian@pocketbeagle2:~/vsx-examples/PocketBeagle2$ cargo run -p eeprom
   Compiling eeprom v0.1.0 (/home/debian/vsx-examples/PocketBeagle2/eeprom)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.99s
     Running `target/debug/eeprom`
EEPROM Data: Contents {
    magic_number: [
        170,
        85,
        51,
        238,
    ],
    hdr1: Header {
        id: 1,
        len: 55,
    },
    hdr2: Header {
        id: 16,
        len: 46,
    },
    board_info: BoardInfo {
        name: "POCKETBEAGL2A00G",
        version: "A0",
        proc_number: "0000",
        variant: "0G",
        pcb_revision: "0G",
        schematic_bom_revision: "A0",
        software_revision: "00",
        vendor_id: "01",
        build_week: "34",
        build_year: "24",
        serial: "PB20000001",
    },
    hdr3: Header {
        id: 17,
        len: 2,
    },
    ddr_info: 4776,
    termination: 254,
}

Blinky

Simple example to toggle GPIOs. Uses Pin P1_20 by default.

Also provides a simple helper function to find PIN by name.

Usage

debian@pocketbeagle2:~/vsx-examples/PocketBeagle2$ cargo run -p blinky
   Compiling blinky v0.1.0 (/home/debian/vsx-examples/PocketBeagle2/blinky)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.50s
     Running `target/debug/blinky`
ON
OFF
ON
OFF
..

MSPM0 Firmware

PocketBeagle 2 contains an MSPM0, which is used as ADC and EEPROM. The MSPM0 firmware can be found here.

Here are the instructions to flash MSPM0:

1. Download the firmware:

wget https://openbeagle.org/api/v4/projects/249/packages/generic/mspm0_adc_eeprom/0.13/mspm0_adc_eeprom.txt

1. Download bb-imager-rs latest version. Currently, that is v0.0.3:

wget https://openbeagle.org/api/v4/projects/832/packages/generic/bb-imager-cli/0.0.3/bb-imager-cli-aarch64-unknown-linux-gnu.tar.xz
tar -xvf bb-imager-cli-aarch64-unknown-linux-gnu.tar.xz
cd usr/bin

1. Flash

./bb-imager-cli flash pb2 --img-local /path/to/firmware --no-eeprom

It is also possible to flash any other custom firmware in Ti-TXT or iHex format.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

• BeagleBoard
• PocketBeagle 2
• Export Symbols RFC
• PocketBeagle® TechLab
• MSPM0 ADC EEPROM Firmware
• BeagleBoard Rust Imager

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

Debian Minimal (non-graphical) image for PocketBeagle 2 based on TI AM6232 processor

Remember to set your user password in the sysconf.txt file located in the fat32 partition before you boot (or use bb-imager and set it in that gui).

• Kernel: v6.12-ti-arm64-r14
• U-Boot: v2025.01-pocketbeagle2
• VSCode: v4.96.4
• Node-RED: v4.0.2

The post PocketBeagle 2 Debian 12.9 2025-01-31 Minimal appeared first on BeagleBoard.

Debian Minimal (non-graphical) image for PocketBeagle 2 based on TI AM6232 processor

Remember to set your user password in the sysconf.txt file located in the fat32 partition before you boot (or use bb-imager and set it in that gui).

• Kernel: v6.12-ti-arm64-r12
• U-Boot: v2025.01-pocketbeagle2
• VSCode: v4.96.4
• Node-RED: v4.0.2

The post PocketBeagle 2 Debian 12.9 2025-01-30 Minimal appeared first on BeagleBoard.

Debian Minimal (non-graphical) image for PocketBeagle 2 based on TI AM6232 processor

Remember to set your user password in the sysconf.txt file located in the fat32 partition before you boot (or use bb-imager and set it in that gui).

• Kernel: v6.12-ti-arm64-r11
• U-Boot: v2025.01-pocketbeagle2
• VSCode: v4.96.4
• Node-RED: v4.0.2

The post PocketBeagle 2 Debian 12.9 2025-01-29 Minimal appeared first on BeagleBoard.

In this video, Andrei shows examples of connecting 5 different MikroE Click Boards to BeaglePlay so you can get started data logging with your next project!

The post Visualizing Linux Sensors with NodeRed & BeaglePlay in 3 Minutes appeared first on BeagleBoard.

In this video, Andrei shows how easy it is to visualize sensor readouts on BeaglePlay using NodeRed!

The post 5 Click Boards in 5 Minutes – Quick Start with BeaglePlay appeared first on BeagleBoard.

One of the design trade-offs when building the BeagleY-AI to conform to a Pi 5 form factor as well as it does was to place the tag-connect JTAG interface for the SoC between the two banks of USB 3.0 ports. As a result, the original retainer clips that come with TagConnect cables do not fit unless you shave down the clip PCB and even then, it’s hard to put in/remove.

To get around this, I’ve designed a simple to print 3D printable piece that serves the same purpose and provides a handy grabbing point so you an can easily insert/remove it.

Both PLA and PETG have been fine but I would avoid printing in something like ABS due to risk of it warping/shrinking and affecting the dimensional tolerance of the holes.

These prints come out perfectly on my Bambu X1C in both PETG and PLA as mentioned above, but you may need to play with scaling depending on the tolerances/calibration of your individual printer and filament.

Happy Printing and Debugging (with JTAG not the print) !

Files are available here –

https://www.printables.com/model/879533-beagley-ai-tagconnect-clip-10pin

The post BeagleY-AI Tag Connect Clip Adapters appeared first on BeagleBoard.

Showcase your BeagleBone AI-64 and keep it from sliding around with this snazzy 3D Printable case! Modify at will and use it as a basis for your next project!

https://www.printables.com/model/547097-beaglebone-ai-64-open-air-case

The post BeagleBone AI-64 Open Air Tray appeared first on BeagleBoard.

I’ve deployed BeaglePlay as a HomeAssistant controller for over a year and a half to run my connected devices. It acts as a rock stable Apple HomeKit bridge to my Matter and Zigbee enabled devices as well as some other more appliances but it deserved more than just laying bare on a shelf so I designed some snazzy cases to show it off and keep it safe! I hope others use these to improve it and design their own!

There are two versions for now:

1. A full enclosure with options for both enclosed antennas as well as external SMA, including options for multi-color printing and cutouts for all expansion ports including Mikrobus.  https://www.printables.com/model/529256-beagleplay-case/
2. A simpler to print tray form factor that still allows easy access to the board – https://www.printables.com/model/576552-beagleplay-mounting-tray

The post BeaglePlay 3D Printable Cases! appeared first on BeagleBoard.

Hello everyone. A typical week for development. Let’s go over everything.

Zephyr Ti Hal Updates

A few weeks ago, I created a PR to update the Simplelink SDK version in hal_ti from 4.40.04.04 to 7.41.00.17. Now that it has been merged, hopefully, I can start working on adding Bluetooth support using the BLE5 Stack in the SDK.

BeagleBoard Rust Imager

More work went into the BeagleBoard Rust imager this week. I hope to get the v1.0.0 release out by the end of this month and replace the old bb-imager.

Introducing bb-imager-service

As mentioned last week, I was searching for how to allow PocketBeagle2 MSPM0 firmware update from the GUI. To reiterate the problem, sysfs entries for Firmware Upload API is owned by root user and thus cannot be opened from the GUI without some kind of privilege escalation mechanism. As a reference, in case of SD card flashing, I am using UDisk2 D-Bus APIs to open the SD card, which internally uses polkit for privileged management.

After some googling, I came across the following stack overflow answer:

• You could, of course, write your own D-Bus service which does that and install the D-Bus .service config to have it run as a system service with root privileges. (Try to keep the operations as limited and fine-grained as is reasonable; e.g. “enable global mode foo” – not “write arbitrary data to arbitrary file”.)
• Failing that, one common method is to spawn pkexec to perform operations, which is… really just su with a nicer password prompt. Note that some distributions have recently removed pkexec.
• If your app is allowed to use either GNOME’s GLib or KDE’s KIO libraries, then both of those already have PolicyKit integration built-in for privileged file updates – the app could open admin:///etc/foo and GLib or KIO would elevate as needed.

Since I could not find much regarding the 3rd approach, and the 2nd approach seemed to be on the way out, I ended up going with a custom D-Bus service. I will probably need similar functionality for BeaglePlay cc1352p7, BeagleY-AI, etc., so it is not a bad idea to have a custom d-bus service.

Using zbus was pretty nice, and I have a better understanding of Linux systems, so it ended up being quite a learning experience. I am building a Debian package for the service for now since it is only supposed to be used in PocketBeagle2 right now. It also contains systemd service which activates on D-Bus connection.

The following articles were a lot of help in figuring everything out:

• Register dbus service
• Creating a D-Bus Service with dbus-python and Polkit Authentication

Overhaul config format

The config format I initially started with differed from RPI-imagers since I thought it would be more efficient. However, after adding a lot of boards and flasher types, I realized that every flashing target is not really a board. For example, having different board entries for PocketBeagle2 and PocketBeagle2 MSPM0 seemed weird.

While browsing rpi-imager last week, I found out that it seems to support bootloader updates in different rpi versions. The GUI presentation seemed nice, so after some deliberation, I adopted a format compatible with the RPI-imager’s format. Since the os_list is a self-referential structure in the RPI-imager’s config, it is possible to have a lot of sub-menus in the image selection menu, which is quite nice.

To elaborate, now there are only base boards (e.g., PocketBeagle2) in the Board Selection menu, and the Image Selection menu will have a sub-menu for MSPM0 Firmware support.

Check out the PR for implementation details.

Live destinations refresh

Similar to RPI-imager, destination refresh is now automatic using subscriptions. Check out the PR for implementation details.

Better defaults in Extra Configuration

The application now queries the user’s current system for the default suggestions regarding username, keyboard layout, timezone, etc. Check out the PR for details.

Include udev rules

I have added udev rules to the Linux package of GUI to allow flashing BeagleConnect Freedom without needing superuser privileges. They also make development easier and allow using commands like tio without root.

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

• BeagleBoard
• BeagleBoard Rust Imager

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

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 PocketBeagle 2 Debian 12.9 2025-01-15 Minimal appeared first on BeagleBoard.

Hello everyone. A typical week for development. Let’s go over everything.

BeagleBoard Rust Imager

Pocketbeagle2 MSPM0 support

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:

1. Does not persist EEPROM contents.
2. Does not support Ti-TXT directly.

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.

Contribution and Packaging Instructions

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.

Better cross-compilation support

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:

• x86_64-unknown-linux-gnu
• aarch64-unknown-linux-gnu
• armv7-unknown-linux-gnueabihf

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.

Export Symbols Devicetree Support

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.

Base devicetree compiler

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.

fdtoverlay

Similarly, I also sent the patch series for support in fdtoverlay. The tests will be added to future versions of the patch.

Future work

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.

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

• BeagleBoard
• BeagleBoard Rust Imager
• Linux kernel export-symbols patch series
• Devicetree Compiler export-symbols patch series
• Fdtoverlay export-symbols patch series

The post This Week in Beagle #10 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.

Pocketbeagle2 MSPM0 Driver

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.

Update Ti simplelink SDK in hal_ti

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.

Fix BeagleConnect Freedom Freeze Bug

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.

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

• BeagleBoard
• Pocketbeagle2
• Pocketbeagle2 mspm0 driver tree

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:

• November 11th: Rust Imager Upgrades and Devicetree Nexus Node Schemas and Dynamic Aliasing
• Novembert 18th: Devicetree Append Properties and Overlays Patches
• November 25th: BeagleY-AI SD Card and Rust Imager Improvements
• December 10th: Devicetree Compiler Path References and Overlay Support

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.

Giving Thanks for Open Source, Partnerships & Community in 2024

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:

• Aryan Nanda’s “Enhanced Media Experience with AI-Powered Commercial Detection and Replacement”
• “Low-Latency I/O RISC-V CPU Core in FPGA Fabric” by Atharva Kashalkar
• “Differentiable Logic for Interactive Systems and Generative Music” with Ian Clester

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.

What We’re Thankful for in 2024

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.

Open-Source Encourages Innovation

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.

Strong Relationships Signal a Strong Future

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.

BeagleBoard Community Continues to Grow

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.

Let’s Shape the Future of Computing, Together

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.