<olerem>
Guest14: interesting, can you use some open source fpga toolchains for this soc?
<PaulFertser>
Guest14: you can try searching for "message:smartfusion" on OpenOCD Gerrit.
Hawk777 has quit [Quit: Leaving.]
danergo has joined #openocd
Haohmaru has joined #openocd
danergo has quit [Quit: Client closed]
<Guest14>
PaulFertser ah! thanks I found exacly the cfg file. I have another question: should I connect remotely to the board in order to flash a new firmware, or is possible to just run the software with the corresponding bin file I want to upload on the board?
<PaulFertser>
Guest14: cfg file is usually not enough for flash programming.
<PaulFertser>
Guest14: I do not understand the next question.
<Guest14>
I explain entirely my problem (sorry for the bad explaination but I'm new to the world): I have a microsemi Smartcontrol2 board which I want to flash through a Raspberry PI with a linux distribution on it. The raspberry Pi and the fpga are connected via USB. Since I need to swap between two different firmware, I would like to automatize the process
<Guest14>
of writing the firmware only using the command line (normally I should use the FlashPro software provided by the microsemi but the linux version do not run on ARM architectures). Is that possibile? Or I need special hardware or similar. Note: I can use also the UART connection for connecte the fpga and the raspebby pi.
<olerem>
Guest14: what do you mean by firmware? fpga bitstream or firmware for the ARM CPU on this chip?
<Guest14>
Hi olerem, it is a bin file which I want to upload on the FPGA
<Guest14>
from the ARM board
<olerem>
Guest14: mit FPGA you mean complet "SmartFusion2 SoC"?
<olerem>
or only FPGA part of this SoC?
<Guest14>
exactly. To do so, I normally use the FlashPro express software on Windows. I just load the bin file and the software recognize the board and write the memory with this bin file (smartcontrol2 connected via USB to the windows computer)
<Guest14>
complete smartfusion2 Soc to aswer to you question
<olerem>
Guest14: ok. smartfusion2 Soc has two parts: ARM CPU + FPGA
<olerem>
your firmware is for which part? CPU or FPGA or both?
<Guest14>
both
<olerem>
Guest14: with other words, yes it should be possible to replace your windows tool, but you need to understand what this tool is doing to know how to replace it
<PaulFertser>
If it includes FPGA part then it should be able to generate an SVF file for you, and then you can play it back with OpenOCD.
<olerem>
PaulFertser: i assume, this blob just need to be flashed to some flash attachet to the soc or integrated in to this soc, and then on start the CPU will upload bitstream to the fpga
<olerem>
Guest14: correct? or do you need to upload this blob without flashing?
<Guest14>
I check the job file, actually this is a process which I didn't implement, so is very hard for me to answer in details. I try to explain as clear as possibile.
<olerem>
Guest14: no problem, but if you wont to do what you wont, you need to go deeper :)
<Guest14>
eheh I see, you are right. I try to understand better what the job file is doing. Come back to you in some minutes
<Guest14>
Looks like that I need to write only the fpga part. And looks like also that with the libero software I can get the SVF file. So do you think can I use this into OpenOCD?
<olerem>
Guest14: potentially yes, if you have jtag access to the fpga part
<PaulFertser>
I remember looking in microsemi software. They are GPL violating arseholes, damn them!
<PaulFertser>
They link OpenOCD with proprietary DLLs.
<Guest14>
crazy
<olerem>
Guest14: since you are customer with some dev board, i'll recommend you contact microchip support and request openocd source code used by the SoftConsole.
joconor has joined #openocd
<PaulFertser>
Along with the DLLs they link it with!
<PaulFertser>
If they refuse to provide GPL-compatible sources for DLLs they MUST stop distributing OpenOCD.
michalkotyla has joined #openocd
borneoa_ has quit [Ping timeout: 264 seconds]
borneoa_ has joined #openocd
The_Jag has joined #openocd
nerozero has quit [Ping timeout: 264 seconds]
xiron has joined #openocd
<xiron>
Hi, I'm trying to debug a Raspberry Pi 4 with the help of a Hydrabus (latest stable firmware). I've tiple-checked the wiring and in Hydrabus console mode I can for example recover the IDCODE (4BA00477). But unfortunately it does not work, see http://paste.debian.net/1219854/. I've also uploaded my configuration, see
<karlp>
where do you see you're getting the idcode?
<xiron>
https://github.com/hydrabus/hydrafw/wiki/HydraFW-JTAG-guide Hydrabus provides a command line utility to work with JTAG. "bypass" returns 1 device and "idcode" returns the correct idcode. That's why I thought the wiring should be correct (besides checking it multiple times, switching wires for new ones, ...).
Haohmaru has quit []
<karlp>
ok, s if you use their tool and get an idcode, and then you use oocd and and that config file, and you get "all ones" I would suspect that the buspirate.cfg file doesn't actually match a hydrabus