Firmware and bootloader initialization specifics

Hello,
First, let me say I support BeagleBoard’s mission. I have a BBB and I am looking to add a Fire to the collection.

In this age of megacorporations techwashing their collaboration with authoritarian governments by “donating” money and providing “free” services, I believe that human rights defenders, environmental activists, and diverse populations need to know their computing environment is 100% safe and open source. To further these goals, I am expecting to replace the entire initialization process, as far up as possible. I do not agree to the GPL principles, so solutions like Das U-boot and Linux need to be replaced. (If you want to publish your source code, be a leader and do so; don’t be a follower and publish just because your license says you have to.)

In reviewing the Beagle documents and the forums, I find there is a lack of information regarding replacing the firmware and bootloader. I have seen posts indicating it is possible to rebuild the bootloader and install it, but not specific instructions on how to. Where is the documentation for this? Will strict adherence to the UEFI bootloader initialization work?

Additionally, a post requested the source code to the firmware. The response was that none existed. This requires a follow-up. Does BeagleBone use any UEFI initialization code in the hardware? What is the source of UEFI code that loads the bootloader? Are the devices requiring UEFI initialization before even the bootloader? Can the devices be initialized with alternative firmwares? Can the firmware be replaced?

I am personally interested in the Fire board because it offers a great opportunity for heterogeneous computing (BSP/AP) and I hope the responses to the above are positive. Please note I do not read Google Groups posts, nor am I on Discourse. I also use Tor so please do not refer me to a web site that uses Google, which routinely obstructs the use of Tor to view web sites.

Thank you,
tim

It gets odder. I think odder is a word. Stay tuned!

Seth

P.S. As a rebuttal to my silliness, there is something called gateware that I noticed in the gitlab stuff. It has a bunch of files, a ton of development done to consider, and I think you may be looking to handle gateware outside of building with the OpenOCD or 05-demos on the docs. pages, and there is some starter stuff to tempt. I saw a debugger of sorts for the PolarFire a while back…

It is called the FlashPro 5. And…I think the bootloader handles the kernel init while the HSS handles the booting. Do not quote me. There are plenty more people whom have been working to handle building around the BeagleV-Fire. I am just a user learning.

I started reading through the Gateware ReadMe, and found the link to Microchip’s repo on Microsoft’s GitHub. In their repo I found references to “silver” licenses, Linux development environments and a link to their documentation. Their documentation appears to indicate that in order to access the FPGA portion of their SoC, you will need to obtain a license from them.

I stopped digging into the matter at that point.

@TimKelly ,

I think there is a python3 file for changing the gateware from openbeagle.org which can be used to handle specifics for the FPGA. I need to double check but I am pretty sure the beagleboard.org people have figured out how to manage the FPGA onboard the SoC. The Silver License is freeware outside of signing in and up. Anyway, look here: BeagleV-Fire / Gateware · GitLab

My posts are being “moderated” so it may be a few days before this actually posts.

I reviewed the licenses. The silver license is only valid for one year and does not enable all features. It is also tied to the Linux and/or Windows development environments.

Circumventing the license is a violation of Microchip’s intellectual property rights. Even the hint of a lawsuit would be enough to cause significant financial harm to Beagleboard.

Code is not documentation.

I tried to delete my account on the beagleboard forums but I have to have permission from the staff to do so. I will not be monitoring further communication on this thread. I have my answers.

1 Like

Thank you for sharing your insights! I completely understand your frustration with the licensing structure. It can feel misleading when boards are marketed with impressive features like GPUs, NPUs, or DSPs, yet crucial details about additional licensing requirements aren’t disclosed upfront. It’s particularly disappointing when those features are a significant part of the board’s value proposition.

That said, while it’s fair to express concerns, it’s essential to respect intellectual property rights, as circumventing licensing agreements could have serious consequences for all parties involved, including the broader community. Clear communication from manufacturers about these requirements could go a long way in preventing misunderstandings.

I hope you find a platform or product that aligns better with your needs. If you ever revisit this space, I’m sure your experiences and knowledge will be invaluable to others navigating similar challenges.

Someone pointed out your post, and I wanted to clarify something. I was not advocating circumventing licensing. My comment was in response to a post suggesting BeagleBoard knew a way around the license. I rigorously adhere to not just the letter of licenses but the spirit as well, which is why I do not review GPL code. The clear intent behind the GPL is to have any subsequent product derived from their code to also be open source. While I support open source vigorously, I do not impose my beliefs on others. I simply share my code publicly. As for Beagleboard circumventing the licenses for Microchip, my comment was intended to convey that I do not believe they would risk financial ruin by attempting such an effort.

I let generative AI compose that response, much nicer than if it was a direct path from fingers. What your observing is why we did not touch that board. When it smells, its best to walk away and find another solution.