Configure FPGA part of BeagleV Fire directly by Libero

Hello, I like to use only the FPGA part of the BeagleV Fire. Is there any possibilty to configure the FPGA with a bit-stream (done in Microchip’s Libero) directly out of Libero?
Because in the documentation there’s a lot of preparation with that gateware (also seems only done at a Linux system)?

My intention was to confirgure the FPGA on the BeagleV Fire on Windows directly in Libero.

Thanks

Sure you can. Just realize you’ll be placing yourself well outside the usual Guardrails.

Make sure you have an FP6 on hand to save yourself when things go sideways. :wink:

@ayush1325 is working on a Zephyr port as we speak, so that’s also a possibility.

Hello, so thanks for the answer. But can you explain a little bit more the detail?
First, what is a FP6 - a programmer, which a can connect via JTAG in case the OS of the SOC-partition of the die is crashed?
Second, thqat means the official workflow for configuring the FPGA is by using the SoC like a programming device? Therefore means, I need to use all the gateware stuff?

Thanks

You are correct; the FlashPro6 is indeed a JTAG programmer.
Once you discard the current bitstream, you are outside the Guardrails
and none of the Docs apply to you any longer; obviously.

As for the second part of your question, I’m not sure if I am answering correctly,
but I think the answer is yes. As I said before, you can very well use
the fabric without caring about the Risc-V complex; it’s just a very expensive
way of going about it. A Cmod-A7/S7 would probably be a much better fit in that case.

(and considerably cheaper too, not that I am trying to talk you out of using BVF)

Ok, so GPT told me something like that (at least I understood like that) ==>

gateware = RISC-V SoC + FPGA Fabric + Device Tree Overlays + Linux Treiber

would you agree with that? In case I override all these content in the SoC, do you know whether some initial bootloader will be always protected? I mean, some piece of loader by which I can enter a kind of recovery mode to reprogram the board with the "BeagleBoard Imager"?

I think you should do yourself a favor and familiarize yourself with
the design of the MPFS family of devices.

The thing that boots first is normally the HSS, followed by u-boot and
in our case the Linux kernel. That being said, all of this depends
on your design. HSS is stored inside a memory area of the SoC; something
you’d know, had you read up on things already.

However, since you stated that you’ll be blowing all of that out of the water,
you really are on your own. No HSS, no u-boot and no Linux, exactly as you wanted.

That also means that even if you could somehow get HSS to show the eMMC
as a disk for Imager to work on, all that’d do would be to rewrite u-boot and Linux.

The bitstream doesn’t live there, so that’d do you absolutely zero good.

Your recovery mode IS the JTAG port, because it’s quite possible;
likely even, that absolutely NO code will be able to run on the E51…

Ok, honestly the concept seems a little bit strange for me - the USB-C is connected to the MSS (like shown in here Design & specifications — BeagleBoard Documentation), and the FPGA fabric is connected to MSS via the FIC.

In the quick start I have to flash an image (which I have already done). But then my expectation would be, that I can configure/program the FPGA via the MSS with a bitstream created in Libero.

Why all these settings and doings in Linux - is there no intention to load bitstreams in the FPGA fabric from Microchips’ toolchain (Libero) and use only the FPGA part??

I have the sneaking feeling that we’re talking straight past each other,
but my initial remark was based on:

The answer was: yes, but using the JTAG port.

Please realize that running Linux is in part to show what the MSS can do
and equally to provide a way to load bitstreams w/o incurring the added charge of an FP6.

In your particular scenario, none of that applies, since you don’t seem to want to use the MSS;
at least that’s what I gathered from your questions.

If I’m wrong, then please rephrase so that I might better understand…

The BeagleV-Fire does not include a FlashPro programming device in the package contents. This would have added more cost $ and there was actually huge shortage of FlashPro’s during the BeagleV-Fire launch during COVID..

The Microchip https://www.microchip.com/en-us/development-tool/mpfs-icicle-kit-es includes a FlashPro in shipping box.

With BeagleV-Fire we preload the FPGA with a golden image and a version of ubuntu (yes from a few years ago) at production time.. Using our tools (gateware) you can design and build an fpga design and can be self-programmed on to the out of box BeagleV-FIre.. Over the years we’ve upgraded the kernel version, images thru bb-imager-rs.. while we test what we can.. if you design something that breaks the fpga, you’ll need either a FlashPro, RPI (directc) etc to re-program the FPGA thru the jtag port..

The physical “USB” port, still relies on a working FPGA/HSS.. so in a blank or mis-programmed state, the onboard USB is useless..

Regards,

Ok, I think I got it now …

There’s no prgrammer on the BeagleV-Fire. The initial image is flashed on the board via USB-C connector. For this a piece of SW (bootloader, whatever …) is runnign in the MSS. On the other hand, to flash the initial image with BB Imaging Utility, a part of the FPGA Fabric is used (the HSIO because here is the MSS located).
That’s what you tried me to explain … if I’d flash/configure the FPGA by Libero somehow, I might kill the MMC part of FPGA fabric and then no more flashing, or MSS at all … only by an ext. programmer then like FlashPro5/6, right?
And the intention of all that, is to write VHDL directly on the Linux (located on MSS), do synthesis on it and directly programm the allowed area of the FPGA Fabric … correct understanding?

That is incorrect… Manufacture uses FlashPro on the manufacturing line..

That got a little convoluted, but basically yes; the HSIOs are owned by the MSS.

I think kill is a strong word to use, but if the MSS is dormant, so will the eMMC be also.

No, that’s wrong. You can develop your Verilog/VHDL on your workstation of choosing.
Only the bitstream need to be brought onto the flash chip somehow;
either by utilizing the built-in Linux or directly via FlashPro6.

My Libero runs Ubuntu 24.04 on a ThinkCentre M920 f.ex…

In fact, I’m pretty sure you’d be quite miserable trying to get Libero to run on BVF directly, if at all.

Ok, but I think I have understood much more from the concept now … even if not completely, but enough for continuing.

Thanks for the patience and good explanations!

One more thing - there is mentioned “… allows connecting to BeagleV-Fire through a browser using IP address 192.168.7.2…” After flashing the Linux and also change_gateware.sh default I don’t see this IPv4 on ETH0 which is up. Do I have to set it manually?

eth0 is the physical RJ45 connector on BVF; that’s normally assigned through DHCP.

192.168.7.2 is the gadget working through USB, this may or may not work,
depending on what you connected that cable to. Look for usb0 in the ip addr list.

beagle@BeagleV:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:04:a3:26:49:49 brd ff:ff:ff:ff:ff:ff
altname enx0004a3264949
inet6 fe80::204:a3ff:fe26:4949/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
3: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
beagle@BeagleV:~$