this is a bit faster :)
ujprog note: supported targets are either -j sram or -j flash but NOT -j sdram sram = fpga internal config temporary active until power off flash = fpga spi config flash, reloaded at each power up
@reostat @daveshah1 multiboot on ECP5 is possible, my "tinyfpgasp" fork uses it, makefile script generates such image using ddtcmd.exe As far as I only this lattice diamond ddt tool can generate multiboot image and prjtrellis has not reverse engineered multiboot format to have ecppack support it. Lattice datasheet about multiboot is missing. There is something on golden image boot but completely wrong (doc full of typos at important HEX numbers and basically same wrong shit copy pasted from ECP3)
It's much worse than the iCE40 though - afaik there is no way to trigger multiboot from fabric
instead you just have to pulse PROGRAMN to switch to the next image in sequence
Yes ULX3S v3.0.3 boards have PROGRAMN wired to some GPIO that way to trigger multiboot switch to next image. ALSO if you solder D28 (near OLED and JTAG header) than you will convert BTN0 function to trigger PROGRAMN
dammit, we need to start board's wiki page on github or something. I mean, the board has lots of peripherals and plenty of potential but as of now all information is scattered over various repos and answers in this channel
the wiki could contain pages like "here's how you communicate with memory", "here's how you do audio/ADC", "here's how you configure pullups/downs on GPIO" etc
for starters, it may contain just some basic info and links to various resources. as we progress we may also fill the repo with useful cores
that is, make wiki a one stop shop for documentation and resources on this board
@reostat I completely agree with you - main problem is that we did not have time for doing it - even me 'insider' do not know lots of features :( Good thing would be that we all in Radiona agrees with you and we plan to do it before April! After small conference where we all would have much better understanding of this board...
happy to hear that. I can really see this board being a huge step forward
We know that we (or anyone else) cannot sell this board if it does not have clear and easy understandable documentations. And that is not something emard should do. That's on us in Radiona and we need to rethink how users will go thru board experience!
I have updated ULX3S doc/MANUAL.md with D28 soldering and funtion note.
pls add note on USER_PROGRAMN and how it can be used for multiboot without diode soldering? I believe schematic says it's connected to FPGA's pin M4
also, your link points to the original TinyFPGA-Bootloader, not to your fork (https://github.com/emard/TinyFPGA-Bootloader)
Im not sure if I programmed it really, but bootloader application tinyfpgasp should after flashing send command to FPGA bootloader to toggle M4 and it will execute fresh uploaded image. Or just re-plug USB and it will do the job without D28
uhm, replugging USB would load the first boot image again, wouldn't it? the bootloader itself, that is
unless you use the bootloader to override the image with bootloader in FLASH - which kinda defeats the purpose )
it's a bird ! it's a plane ! no, it's an unfinished softcore !!!
sooner than later we're gonna have a whole gallery. the one above would go as "pooping bird"
heehehe
or a pigeon, rather
heh
@reostat regarding bootloader: HI I forgot to say replugging to USB charger which is not PC and won't enumerate (you can use 2 cables and power for US1 optionally). If US2 can't see PC on otter side any longer, it will pull PROGRAMN to skip itsel fbootlaoder) and load user bitstream. Bootloader is somehow "smart"
@tobias we have our local user with apple laptop, can you tell me your e-mail if he can't install prjtrellis toochain so you can help him?
I've published my latest ramblings on my ULX3S (thanks @emard @daveshah1 @goran-mahovlic @reostat )
second quote is no longer true, tedious process is for SVF but ujprog -j flash file.bit should flash easily
updated! thanks
sxpert @sxpert bookmarks
I have also updated ulx3s-passthru source with new makefile and it builds with prjtrellis now
use "universal-make" directory, vhdl2vl does the job
@emard re vhdl2vl, this one? https://github.com/ldoolitt/vhd2vl
Yeah, that's the one
dave, someone asked is there some chance to have serdes soon. I guess it's difficult as serdes is not only elementary silicon block but also partly in a encrypted IP core - am I right?
No, there is no encrypted IP core
The cores that actually use it are encrypted but you don't need them if you start from scratch
It should otherwise work fine with nextpnr
whitequark started working on a PCIe core: https://github.com/whitequark/Yumewatari
I see, this is encouraging if serdes block can be used standalong! And I have another question, are ordinary differential (non-serdes) IO pins capable to handle pcie x1. i am thinking about PCIe ram expansion.
No, PCIe runs at fixed data rates and a minimum of 2.5Gbps so has to use SERDES
You could run PCIe protocol on IO pins at lower rate but no other existing devices would work with it
I see, serdes speed is required for normal PCIe (or in some marginal case if someone finds or hacks PCIe card that canlower its protocol clock)
I wouldn't expect any existing card to work at such a low rate
serdes was my request
OK no chance of PCIe for ULX3S :). What is about multiboot image support - is your research now enriched with more information of ECP5 boot "assembly instructions code" so we can do multiboot image from ecppack, without this annyong ddtcmd.exe?
having next revision (or call it the upscale version of current one... ULX3S-MEGA?) with LFE5UM-85 or even LFE5UM5G-85 and FT2232H with second channel wired to FPGA would be my dream-come-true :)
emard: no, haven't looked at multiboot
as for multiboot, I still have no idea how to make the multiboot image (preferably with more than 2 configurations) and only a faint idea of how to trigger it (jerk USER_PROGRAMN low?). I guess I just need to read the sources of your fork of TynyFPGA-Bootloader but... there's too much sources to read on my plate already
I mean, for ice40 the process is clear: use icemulti to combine up to 4 images into 1, then use SB_WARMBOOT to switch between them
for ecp5, not so much clear
Yeah, there is no equivalent to SB_WARMBOOT
yes ULX3S MG = Muchacho Galante edition, with FT2232 and serdes wired to HDMI or something.
I figured thus far :)
Asserting PROGRAMN should move to the next image in sequence
between all 4 configs in cycle?
Or however many you have
multiboot: i did some research and succeeded generating golden image (failsafe) from my python script but still multiboot mode I don't understand
and what are the offsets the images must be located at in flash? or does every image need to have a pointer to the next one in some format?
see, lots of questions (
You can have a bitstream that connects BTN0 to PROGRAMN or solder a D28 diode to experiment with multiboot
ok. so I have img1.bit, img2.bit and img3.bit. each one, say, wires USER_PROGRAMN to ~BTN_DOWN
what do I do with them next?
ECP5 so to say has a 16/32 bit CPU that manages multiboot. Its assembly is executed from last 256 bytes of SPI flash and I think golden/failsave images can be anywhere but for multiboot I'm not sure can it really be the same
we don't have proper documentation of this assembly instructions. Only reversenginnering from ddtcmd.exe can reveal something. Great problem is that ddtcmd.exe also patches primary bitstream somehow and then I'm stuck to follow what happens further and how user can make multibuoot from opensource
btw why are you guys up? isn't it past midnight in Europe? :)
we use GMT UTC time :)
ditto
ok, ok, almost past midnight
@emard do you have a ddtcmd multiboot image to hand that you can send?
yes of course I can come up with something, my tinyfpga bootloader fork makes them from makefile lemme check does it still compile to binary
@daveshah1 if you're goint to do what I think you're going to do then you need both the original images and the resulting multiboot one
I first want to see what the patches are
dave: can you use my makefile from my patched tynyfpga bootloader the makefile has exact process of ddtcmd invocation and you will see that it patches primary bitstream somehow TinyFPGA-Bootloader/boards/ulx3s-v2.0-85f-sp$ make
another question is if the process is the same for only two images and for more than two images
I think this is main invocation that makes multiboot: LANG=C ${DDTCMD} -dev $(FPGADEVICE) -oft -advanced -format int -flashsize 128 -header -quad 4 \
-if $(PROJECT)/$(PROJECT)$(PROJECT).bit \
-golden $(PROJECT)/$(PROJECT)$(PROJECT).bit \
-multi 1 -altfile $(PROJECT)/$(PROJECT)$(PROJECT)_altfile.bit -address 0x200000 -next prim -of $@
-if $(PROJECT)/$(PROJECT)$(PROJECT).bit \
-golden $(PROJECT)/$(PROJECT)$(PROJECT).bit \
-multi 1 -altfile $(PROJECT)/$(PROJECT)$(PROJECT)_altfile.bit -address 0x200000 -next prim -of $@
altfile is actually initial copy of user's bitstream going to 0x200000 which can be overwritten and to which it skips on PROGRAMN pull down. ddtcmd fiddles something with temporary files during patching and erases them, stopping it in the middle of the process of linux could reveal something probably too
yeah, reading ECP5 docs I thought the same: altimage is the primary image, golden one loads only if altimage fails (or on trigger)
altimage can be same binary but must be a different copy (not symlink) because when ddtcmd patches primary it would (if symlinked) patch also the altimage and then multiboot won't work. I don't know more details apart that it appears so
golden image is loaded if primary is damaged. I don't know can we have multiboot without golden image. ddtcmd has no option to make it without golden.