Hey…I just used the bb-imager-rs source code to boot an image on the BeagleV-Fire. The source code for bb-imager-rs stated it uploaded just fine. Then, I tried to boot the board via eMMC. Should I be using micro SD Card instead? I will test this in the meantime while someone looks this over…
[ 2.162017] mpfs-generic-service mpfs-generic-service: Registered MPFS generic service - FOR DEVELOPMENT ONLY, DO NOT USE IN PRODUCTION
[ 2.174908] mpfs-sys-controller syscontroller: Registered MPFS system controller
[ 2.426054] mmc0: error -110 whilst initialising MMC card
[ 2.701417] mmc0: error -110 whilst initialising MMC card
[ 2.868012] clk: Disabling unused clocks
[ 2.873444] Waiting for root device /dev/mmcblk0p3...
[ 3.030384] mmc0: error -110 whilst initialising MMC card
[ 12.405807] spi spi2.1: deferred probe pending
See. mmc0: error? Anyway, I will keep trying.
You need to see what happened a bit further up in that log…
Your snip is too little to go on!
1 Like
I got it. I think I had TX to TX. Blah. Either that…or?
I may have installed the image from bb-imager-rs and had a stale version on the eMMC.
Update
I am wrong as usual…
---------------------------------
-- BeagleV-Fire --
---------------------------------
[1.568008] PolarFire(R) SoC Hart Software Services (HSS) - version 0.99.36-BVF-0.3.0-2-g3d347fe
MPFS HAL version 2.2.104 / DDR Driver version 0.4.023 / Mi-V IHC version 0.1.1 / BOARD=bvf
(c) Copyright 2017-2022 Microchip FPGA Embedded Systems Solutions.
incorporating OpenSBI - version 1.2
(c) Copyright 2019-2022 Western Digital Corporation.
[1.599951] Build ID: a005e1b75f7d76f2d655de2436e1430de6129dab
[1.606808] Built with the following tools:
- riscv64-unknown-elf-gcc (xPack GNU RISC-V Embedded GCC (Microsemi SoftConsole build), 64-bit) 8.3.0
- GNU ld (xPack GNU RISC-V Embedded GCC (Microsemi SoftConsole build), 64-bit) 2.32
[1.628682] NOTICE: Running from L2 Scratchpad
[1.634324] Serial Number:
db96109fc41c50561245f0109b700f0a00000000000000000000000000000000000000000000000000000000000000000000
[1.646997] Segment Configuration:
Cached: SEG0_0: offset 0x0080000000, physical DDR 0x00000000
Cached: SEG0_1: offset 0x1000000000, physical DDR 0x00000000
Non-cached: SEG1_2: offset 0x00c0000000, physical DDR 0x00000000
Non-cached: SEG1_3: offset 0x1400000000, physical DDR 0x00000000
Non-cached WCB: SEG1_4: offset 0x00d0000000, physical DDR 0x00000000
Non-cached WCB: SEG1_5: offset 0x1800000000, physical DDR 0x00000000
[1.687879] L2 Cache Configuration:
L2-Scratchpad: 4 ways (512 KiB)
L2-Cache: 8 ways (1024 KiB)
L2-LIM: 4 ways (512 KiB)
[1.702375] DDR-Lo size is 32 MiB
[1.706628] DDR-Hi size is 1888 MiB
[1.730472] Design Info:
Design Name: DEFAULT_A455AEAB364A52CD54CD61
Design Version: 02.00.3
[1.740888] Attempting to select eMMC ... Passed
[1.995698] User button NOT pressed
Press a key to enter CLI, ESC to skip
Timeout in 1 second
.[2.05246] Character 32 pressed
[2.09326] Type HELP for list of commands
[2.14100] >> mmc
[6.52964] Selecting SDCARD/MMC (fallback) as boot source ...
[6.59474] Attempting to select eMMC ... Failed
[6.959400] >> usbdmsc
[10.988621] initialize MMC
[10.992180] Attempting to select eMMC ... Failed
[11.892278] FLASH_DRIVE_init() returned false...
[11.898007] >> emmc
[16.577386] Selecting EMMC as boot source ...
[16.582594] >> usbdmsc
[21.55294] initialize MMC
[21.58766] Attempting to select eMMC ... Failed
[21.958778] FLASH_DRIVE_init() returned false...
[21.964507] >>
Does that work?
That makes no sense; you wouldn’t have seen anything in that case.
Furthermore, BeagleV-Fire doesn’t boot from SD…
(well, except the one on my desk, that is)
1 Like
@lranders ,
Can you look over what I have done so far? I added some new additions to the error(s)…
I just did. Your Gateware is extremely old. You should consider loading a newer version.
I can’t quite make out if that “DEFAULT” build is stock or one of your own creation,
but in any event, your HSS is way outdated and needs some help.
1 Like
Okay. Thank you. I understand now. I will try to flash a new image and update the old Gateware if the image cannot flash.
Unless you have an FP6 on hand, you could be stuck.
Please power-cycle the board to see if that brings back the eMMC…
1 Like
I have the FP5 only. I am stuck. Every now and then, the board boots and I can see it booting but then the end result is a cycle. It ultimately turns into a loop upon loop. I will try what I can…
Thank you.
Yes, in your situation, you really need to get back into Linux
and straighten out that Gateware.
Reprogramming the HSS via JTAG will just get wiped once the PolarFire
updates itself from the SPI flash…
Unfortunately, the FP5 isn’t able to clear the SPI.
1 Like
Gotcha. There is something happening now. I performed these commands…
mmc
mmc
usbdmsc
Now, for some reason, it seems like it is flashing something without error…
I will update you shortly. Oh!
Is BeagleV-Fire supposed to shut itself down after a successful flash?
I couldn’t say. It’s been more than 2 years since I’ve seen that.
(0.3.0, that is…)
By the way, BeagleV-Fire can’t “shut down”; it’s not a BBB with a TPS chip.
So if you’re seeing “shut downs”, I’m getting suspicious about your power-supply…
Well, either that or your board is just plain overheating, which could lead to an unstable eMMC.
You can help the little fella by putting a fan on it to take away some of the over-stress.
In the interest of disclosure, I always have a little Noctua fan keepin it cool…
Whelp. No go. I thought I had it and blah, notta.
I will keep testing to see if the Gateware can be updated somehow.
Any luck getting your Beagle back into Linux?
In your current predicament, getting Linux to work is paramount,
because we need it to be able to reprogram the SPI.
Any attempt to use your FP5 in the current state
won’t help, as the system-controller will overwrite whatever
you put in, because the FP5 isn’t able to clear the
contents of the SPI flash, and you’ll keep being stuck
in that boot-loop…
Additionally, I really urge you to employ a fan to keep the eMMC from acting up.
(any fan will do)
Hey @lranders ,
First off, no. No luck on my end trying to get Linux to boot so far. Well, I take that back. It booted and then went into a loop for some reason.
FP5 is all I have now. If it becomes an issue and me learning is more important than it is now, I will think about getting the FP6 to reprogram the SPI.
Thank you for checking back. For now, with the state of life and this house, plumbing is more important right now. So, the FP6 is a no-go for me as current.
I will try some more tonight a bit later.
@lranders ,
I got it. For some reason on Debian Trixie, I could not get the BeagleV-Fire to boot on Debian or Ubuntu images. Now, with WSL2, I got Ubuntu to boot on the BeagleV-Fire!
In it to win it again!
I will read the docs now to update the gateware.
Update
I think my debian distro does not carry the headers. Blah. I will test later…
I am trying to update/upgrade now. I am receiving error(s). Please see the attached snippet.
The following packages will be upgraded:
linux-firmware
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
158 not fully installed or removed.
Need to get 0 B/560 MB of archives.
After this operation, 50.0 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Reading changelogs... Done
(Reading database ... 40422 files and directories currently installed.)
Preparing to unpack .../linux-firmware_20240318.git3b128b60-0ubuntu2.25_riscv64.deb ...
Unpacking linux-firmware (20240318.git3b128b60-0ubuntu2.25) over (20240318.git3b128b60-0ubuntu2.14) ...
dpkg: error processing archive /var/cache/apt/archives/linux-firmware_20240318.git3b128b60-0ubuntu2.25_riscv64.deb (--unpack):
cannot copy extracted data for './lib/firmware/mediatek/WIFI_RAM_CODE_MT7922_1.bin.zst' to '/lib/firmware/mediatek/WIFI_RAM_CODE_MT7922_1.bin.zst.dpkg-new': failed to write (No space left on device)
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/linux-firmware_20240318.git3b128b60-0ubuntu2.25_riscv64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
I rebooted and it boots but something is taking up too much space presumably.
cd /usr/share/beagleboard/gateware
. ./change-gateware.sh default
Those are the commands to handle updating the gateware supposedly. For now, my file change-gateware.sh is handled by root:root.
I cannot change the gateware without sudo permissions or signing in as root. Right?
ls -l change-gateware.sh : -rwxr-xr-x 1 root root 766 Jan 7 13:22 change-gateware.sh
Send guidance in time, please. I am not sure what to do about the space which is at 100% and my older gateware versioning without soft bricking the board for now.
anyway…before I reboot to test whatever is taking up too much room found through df -h and other tools, please see the below text…
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
See…oh and…
Filesystem Size Used Avail Use% Mounted on
/dev/root 3.6G 3.4G 0 100% /
tmpfs 772M 0 772M 0% /dev/shm
tmpfs 309M 1.6M 307M 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/mmcblk0p2 128M 9.1M 119M 8% /boot/firmware
tmpfs 155M 8.0K 155M 1% /run/user/1000
Yes, for some reason Debian doesn’t always grow the volume to it’s full size;
I’ve seen that happen more than once myself…
But it’s good that you, once in a while at least, is still able to get into Linux.
Did you try and add some cooling, as I suggested?
Brian reminded me that you might not need that FP6 after all, so all is not lost.
One thing though:
Don’t rely on apt to bring you the latest and greatest Gateware.
Sometimes it’s lagging behind a bit, but on the other hand,
it’s going to be quite a bit newer in any event.
First things first though; you’ll need to get that partition grown to full size.
(a reboot is required for it to show up)