I’ve got the following files:
from this link … Releases · beagleboard/u-boot-pocketbeagle2 · GitHub , placed on partition 1 (FAT32). I’ve tried, screen, tio, and even moved to an Ubuntu machine … to no avail. My user is in the dialout group. The terminal png below is with the command screen /dev/ttyACM0 115200, but no matter which serial program I use, all same results.
Those are not the 3 files I listed here… Building for PocketBeagle 2 ... - #10 by RobertCNelson
Extra request, take a photo with your phone how you have the serial wired up.
So, I had actually tried those 3 files in the past as well, same results. But downloaded again, and same results. Photo attached. There’s no hub involved, this is directly to USB ports on machine.
I’m wondering about the meaning of this line. I’m using the same partitions I had for the BBB for the PB2. Partition 1 is FAT32, and partition 2 is ext4. But it says “unlike the BBB, K3 only works with FAT so create normal fat32 …”, which is what I thought I had. Can this be clarified?
IIRC this is usually to do with Das Uboot - the almost universal boot loader for arm. Uboot needs to access the file system, e.g. to load the kernel from flash into memory. This means uboot needs to understand the file system that the kernel lives on. uboot’s understand of file systems used to be a bit limited, e.g. IIRC you had to disable metadata_csum and 64bit for uboot to read ext2/4 filesystems. Anyway uboot has moved on, its now far better at handing things.
Robert will know the details for the PB2 …
We use raw boot on am335x, so u-boot is stored in the MBR.. so you don’t need, fat, or even ext4… As long as u-boot supports the file system.. for example btrfs!
K3 Arch pretty much needs fat, unless you use external spi flash..
Oh! Does uboot understand btrfs now! Thats a huge leap forward!
I can’t imagine what’s going on. I changed the first partition to a btrfs partition on a 4GB sd card and am still seeing the same results. parted print shows my SD card as:
Model: Mass Storage Device (scsi)
Disk /dev/sdc: 4027MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 134MB 133MB btrfs primary boot, esp
2 134MB 4025MB 3891MB primary
So, just ordered a few more PB2 boards to see if there’s something going on with this board I have.
Why are you using gpt? All my examples use MS-DOS…
Ugh, another last minute change I did trying to get anything and everything to work.
Ugh, thought deleting the last post and replacing it with this one would be cleaner. I was trying to recreate and clarify details with this post in my latest attempt for something that shouldn’t seem like a problem, but is for some reason and doesn’t allow the board to display a u-boot prompt. I just get a lot of junk symbol like output from terminal emulations (photo posted in previous post). I’m pulling my hair out.
Partition one on /dev/sdd (sdd1) is type fat32 known as /dev/ttyACM0 to tio, screen, or minicom and has the following files …
$ ls -l
total 2092
-rwxr-xr-x 1 root root 282738 Jul 7 20:52 tiboot3.bin
-rwxr-xr-x 1 root root 952067 Jul 7 20:52 tispl.bin
-rwxr-xr-x 1 root root 906383 Jul 7 20:52 u-boot.img
… downloaded from this link, Releases · beagleboard/u-boot-pocketbeagle2 · GitHub of this release, v2026.01-am62-pocketbeagle2-11.02.11
For the listing above, I mounted sdd1 to /mnt/usb during which I also ran lsblk to show this:
$ lsblk /dev/sdd
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sdd 8:48 1 3.8G 0 disk
├─sdd1 8:49 1 63M 0 part /mnt/usb
└─sdd2 8:50 1 3.7G 0 part
The 4GB SD card is formatted as follows:
$ sudo fdisk -l /dev/sdd
Disk /dev/sdd: 3.75 GiB, 4026531840 bytes, 7864320 sectors
Disk model: MassStorageClass
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x87a6d8e5
Device Boot Start End Sectors Size Id Type
/dev/sdd1 * 2048 131071 129024 63M c W95 FAT32 (LBA)
/dev/sdd2 131072 7864319 7733248 3.7G 83 Linux
My new PB2 boards just came in and those are showing the same problem in the photo above (unable to read the output, junk symbols) so all I can assume is that it’s something with either the binaries that I’ve got on the partition or not understanding exactly which binaries are needed just to get to a u-boot prompt.
Was hoping someone could look over my work.
UPDATE: I used the bb-imager utility to write a Debian image on a 32GB SD card and I’m seeing the 4 user LED’s light up and “appear” to be working by blinking the way I’d normally expect. Yet, it too is outputting the same trash on the terminal console. Starting to wonder if a cable or the Pi debugger is bad.
UPDATE 2: I think I’m starting to see what’s happening.
I was able to get an image with bb-imager working which I used to write a Debian image onto a 32GB card and noticed it creates two /dev/ttyACMx devices. /dev/ttyACM0 when I plug the Pi debugger in, and then only when the kernel boots does it create /dev/ttyACM1 which requires that I have the terminal emulator connected to that device (ttyACM1, not ttyACM0). Then I’m seeing text come through the terminal properly.
So … on my image, as I only have what should get me to a u-boot prompt and because I don’t have the kernel or rootfs loaded yet, I’m thinking maybe I won’t be able to get a u-boot prompt from the only ttyACM0 (at this point) … which seems strange. I guess I’ll have to get the kernel and the rest of the rootfs together with the goal of getting /dev/ttyACM1 created before I can properly see output in the console.
Will now do some testing as to why I have a Pi debugger.
Thoughts on any of this?
As for the Pi Debug Probe, I can’t help thinking your “gibberish”
is due to the serial stream not at 115200, like normal.
Try slapping a scope or logic probe on the PB2’s TX and ascertain the
correct bitrate that way. I’m pretty sure that will give you “picture” quite fast.
To clarify, if I move to ttyACM1 (as opposed to ttyACM0), I no longer get the “gibberish”. What I don’t understand is why two ttyACMx devices are created, one when plugging in the RPI debugger, and another after the kernel boots and is also the one that allows me to see non-gibberish messages. But this is contrary to apparently what everyone else is doing. The terminal emulators default to 115200 and I’ve even specifically stated that in previous tests above, to no avail.
I think I’ve got enough to get me back on tracking and continue towards further progress, though strange why I’d have to do this. Maybe it’ll become clear down the road.
Can I get a link to which repo and tag is being referred to here in building the kernel?
You need to realize the kernel on your monitoring machine numbers the channels dynamically.
Instead of getting hung up on numbers, lets just call them ttyACM<d> and ttyACM<k>.
Your ttyACM<d> is the only one able to capture what’s going on while the PB2
is booting, which is why I’m so interested in getting it working.
The ttyACM<k> is created by the kernel and it should be obvious why that one
can never show us the interesting bits…
While the terminal emulators default to 115200, I’m sure they’re more than capable
of doing other line-rates, once told explicitly to do so.
I’m thinking at this point, you have 3 options:
In any case, the reason you see one or more ACM’s should now be clear to you.
Thats strange. Assuming you can get log on the PB2 e.g. via ethernet, you should be able to get the speed using something like stty -F /dev/ttyGS0 -a. But something odd on my machine as well - I’m logged in over the UART brought up on the USB, that is ttyGS0 - and the above command says the speed is 9600 - but I logged in at 115200! Let me try the external UART …
… hmmm mine is glitching as well - But my PB2 is having an error on boot Unable to handle kernel paging request at virtual address ffffffff80000140 … let me dig into that and get back to this thread …
What is worth saying, is if you can show that the PB2 has configured the speed to 115200 on both UARTs that you tried - and this work on other PB2s, there you almost certainly have a hardware fault on the main UART that means you get garbage. But to conclude this need to show the PB2 has brought up the UART as expected …