In the interest of a proper post-mortem, could you please describe the full
set of events that led you to the current situation?
Did you just pop it out of the bag and landed in hot water?
Have you been loading your own Gateware?
Were you following bad instructions on the Docs?
In short, we want to learn from your conundrum, so if there’s anything we can
do to improve the documentation, we’re all ears!
Hey @lranders ,
History of events:
tio /dev/ttyUSB0 to boot and read data while the kernel came up.Some instructions are outdated or not used:
sudo permissions.Then…new build. I used artifacts from openbeagle.org and booted the machine after some issues with looping. Still, every time, the Trixie builds worked and I could see them on my network as BeagleV at an IP Address.
And…the Ubuntu versions worked as I could see them on the IP Address sections to attached machines on the network.
For instance, each version of Debian and Ubuntu from openbeagle.org would go into looping. I finally got Ubuntu to work but I am currently out of eMMC storage. I rebooted already and still am in the full eMMC data conundrum.
Just to reiterate, the reboot did nothing about eMMC on my current image.
You’re right.
Once it gets into this “un-grown” state, it’ll stay like that unless
you execute it manually; the details elude me at the moment,
so you’ll have to dig into that.
You’re just pointing to openbeagle.org, which is slightly unhelpful.
Could I ask you to post the entire URL?
Just to make sure I’ve understood you correctly:
You have never updated your Gateware; just the eMMC image.
When I say updated, that also covers loading your own variation of it…
Furthermore, you keep using the word “looping”.
Please elaborate!
The looping is over now. I cannot elaborate.
and right, I have not recently loaded my own version of gateware.
You could at least try to describe exactly what you mean by it…
Is it doing a complete reboot with all the bells and whistles
or is it just resetting itself and starting, midway.
Remember, I can’t see whats going on at your desk,
so you’ll have to be my eyes…
You already mentioned something that could be interpreted as a flaky power supply,
so naturally, I’m trying to rule that out. Make sense?
Now you’re saying “not recently”. Could that explain why I can’t find the SHA
of the Gateware, which is currently on your Beagle?
Also, you still haven’t answered my question whether you’re cooling your
Beagle for stability or not. I would very much like to know…
Okay. I can try…
By looping, the u-boot or whatever is used to boot the board, HSS or whatever, kept running through a loop. So, I plug it in and see the boot log while it boots. Then, I can either hit any key to stop booting and get into (u-boot or whatever boot faculty is on it) or let it boot.
When I stop it to put in the commands, emmc or mmc or usbdmsc, it fails and the output states something in red and stops. If I allow it to keep booting, it loops from beginning to end to beginning and etc.
“Not recently,” means that I have not updated the gateware recently, i.e. in the last six months.
“Not recently,” also means that the gateware, which was not a self-made versioning, may have not ever been updated or installed.
If you want the gateware version, please let me know. I will get to the version.txt file.
Oh. You were asking about cooling. I thought you were telling me. Sorry. I do not have a fan handy right now. I am not cooling it.
You already sent the Gateware version in the second snip
and I’m satisfied that we aren’t talking about a “homegrown” variant.
Right, so the “looping” wasn’t from the kernel and forward,
it was the HSS repeatedly dying and restarting itself.
See? The “fine print” is important…
Ok, I think you should do yourself a favor and get that fan to keep everything cool.
I know, it sounds odd, but especially the BVF-0.3.0 firmware makes the whole
thing run hotter than it should be.
Any fan will do, it doesn’t even have to be driven by the Beagle itself…
Right now we just need to get into Linux so we can replace that Gateware with
a version that is a bit more stable than what you currently have.
So, cooling first and then we look at getting that partition grown,
once your Beagle is stable enough to start Linux.
Sound like a plan?
2025.10-2-g4e16f48 is my version.txt data from output.
I have a fan now. I found one. Also, I have a blinking LED on it now instead of lit LEDs only.
version 0.99.36-BVF-0.3.0-2-g3d347fe was your original snip…
How can I search for the versions you need to see? I am on Linux now instead of the debug headers for testing and setting up.
It’s the very output you sent us from the HSS.
2025.10-2-g4e16f48 is my current BVF_GATEWARE versioning.
That other log of the HSS boot log is old now.
Should I go back to HSS to handle getting the BVF_GATEWARE versioning?
What is the partition that needs to be resized on the BeagleV-Fire?
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 14.6G 0 disk
├─mmcblk0p1 179:1 0 560K 0 part
├─mmcblk0p2 179:2 0 128M 0 part /boot/firmware
└─mmcblk0p3 179:3 0 14.5G 0 part /
mmcblk0boot0 179:256 0 4M 1 disk
mmcblk0boot1 179:512 0 4M 1 disk
Never mind me. The eMMC is full and I do not know what to do for now. One command shows 4.5GB and full while the other command shows 14.5 for a specified partition.
I’m not ignoring you, I just needed to get something to eat…
The part in question is /dev/mmcblk0p3.
The partition knows it’s correct size, but the fs on it still thinks it’s 4GB.
Do a sudo resize2fs /dev/mmcblk0p3, sync and sudo reboot.
I will test it. I read about resize2fs but was currently unsure if that route was needed.
Oh and sir, no issue. There is no issue about eating or taking a while to reply, i.e. as I eat and sometimes take a while to reply/respond.
As I said, if you want to know for sure exactly what Robert is doing,
you’ll need to trawl through the systemd tasks;
this is just what ChatGPT spat out…
Yeppers. I can research more…
I am making a slip-on holder for the BeagleV-Fire so my metal fan does not interfere with the circuitry on the BV-Fire.
Well, it is a plastic fan but has a metal enclosure grill that protects the fan. I do not need that metal on the grill coming in contact with the BV-Fire and its components.
Just in reply here to sudo resize2fs, it works and fine. Thank you.
I appreciate you replying @lranders and coming up with that spot on search with the command. And also here:
total 52
drwxr-xr-x 11 root root 4096 Mar 27 01:24 .
drwxr-xr-x 3 root root 4096 Jul 21 2025 ..
drwxr-xr-x 5 root root 4096 Jul 21 2025 board-tests
drwxr-xr-x 5 root root 4096 Mar 27 01:24 cape-4-uarts
drwxr-xr-x 5 root root 4096 Mar 27 01:24 cape-comms
-rwxr-xr-x 1 root root 766 Jan 7 13:22 change-gateware.sh
drwxr-xr-x 5 root root 4096 Mar 27 01:24 click-boards
drwxr-xr-x 5 root root 4096 Jul 21 2025 default
drwxr-xr-x 5 root root 4096 Jul 21 2025 minimal
drwxr-xr-x 5 root root 4096 Jul 21 2025 picorv-apu
drwxr-xr-x 5 root root 4096 Jul 21 2025 robotics
drwxr-xr-x 6 root root 4096 Mar 27 01:24 sin-shls-apu
-rw-r--r-- 1 root root 19 Jan 16 20:24 version.txt
I noticed some of the local board, BeagleV-Fire, configurations for different gateware.
Have you tried any of them or should I hold off?
Kernel: 6.6.75-linux4microchip+fpga-2025.03-20250721+
Image: BeagleBoard.org Ubuntu 24.04 Console Image 2025-07-21
Those are my image and kernel parts to the board so far (as of today).
Compared to what you have now, I’d say it can’t possibly hurt…