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 :slightly_smiling_face: ? 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 [email protected] 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 https://github.com/tinyfpga/TinyFPGA-B-Series/issues/10#issuecomment-347022533, 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 :smile: 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 :wink: