Lost warmboot capabilities after recompiling bootloader

[facchinm]

Hi Luke,
first of all, thank you!!! Your project is super cool.
I was studying the bootloader code to integrate some parts into another project;
after recompiling it with iCeCube 2017.01.27914 (on Linux) and flashing it at address 0x0 it looks like the "bootloader" feature (warmboot) disappeared. I can flash the bootloader over itself just fine, I can also flash an "application" at 0x30000 but it doesn't "boot" it.
Am I missing something obvious? Could you share the actual bitmap you are flashing in production so I can try it and report if it behaves differently?
Thanks a lot and keep on with your awesome project!

[tinyfpga]

There is some special sauce that needs to go into the bitstream to enable warmboot. It basically is like a header that tells the warmboot feature the addresses of the different configuration images.

I have posted the original firmware on the discourse: http://discourse.tinyfpga.com/t/programmer-for-b2-dodgy/86/28

I’ll try and write up instructions on how to enable the warmboot feature soon. You have to use the Lattice deployment tool to process the bootloader bitstream and a dummy user bitstream. It combines them both into one file along with the necessary vector information.

[facchinm]

Sorry to bother you but I'm still unable to bring the bootloader back to life.
Renaming it to hex doesn't make tinyfpgab programmer happy (it expects a clean hex file, I believe).
Running hex2bin produces a suitable binary (the size is 331KB) but flashing it doesn't bring the ACM interface back. Am I (still) missing something 🙂 ?
Thanks again!

[tinyfpga]

What hex2bin utility are you using? Not sure it supports intel hex correctly. Give me some more info on the utility you are using and where to find it.

…

On Sun, Nov 26, 2017 at 8:54 AM Martino Facchin ***@***.***> wrote: Sorry to bother you but I'm still unable to bring the bootloader back to life. Renaming it to hex doesn't make tinyfpgab programmer happy (it expects a clean hex file, I believe). Running hex2bin produces a suitable binary (the size is 331KB) but flashing it doesn't bring the ACM interface back. Am I (still) missing something 🙂 ? Thanks again! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AcnVg3uLejU8jUQBn3TMbGE4wI1Wnwr-ks5s6ZfdgaJpZM4QqyDa> .

[facchinm]

I'm using https://sourceforge.net/projects/hex2bin/?source=navbar with default parameters. The output looks sane; FYI, I'm following this procedure:

mv fw.mcs fw.hex
hex2bin fw.hex
tinyfpgab -p fw.bin -d 2341:8037 -a 0

[facchinm]

I've been able to overcome the problem in this way:

• Pad some blank to the compiled booloader bitstream

dd if=/dev/zero of=blank.bin bs=1 count=90000
cat TinyFPGA_B_bitmap.bin blank.bin > TinyFPGA_B_bitmap2.bin

• Use icemulti to enable multiboot features

icemulti -c TinyFPGA_B_bitmap2.bin -a10000 -p0 example.bin -v -o /tmp/fw3.bin
tinyfpgab -p /tmp/fw3.bin -a0

This way it looks like it's working; I'm attaching the resulting bin if anyone is interested; I'll close the issue as soon as I make sure there is no side effect in this procedure.

tinyfpga_bootloder.zip

[tinyfpga]

Hey @facchinm, can you confirm your method is working with no side-effects? If so, I can add this to the documentation.

[facchinm]

It's working like a charm 😄 The only "problem" is that icemulti tool is much better at arranging the partitions at power of 2 boundaries, so 0x30000 doesn't play well with it. I finally decided to leave the default 0x20000 (since the bootloader fits in it) and get a bit more space in the flash. But to achieve it I had to modify the flasher so it's not really a neat workaround but I'm fine with it 😉