Building from source for GNU Guix (was: Stuck in DFU mode)

[rekado]

Maybe diff the output from arm-none-eabi-objdump disassembling axoloti.elf rather than the binary code?

That's a good idea. I'll try that.

[johannes]

If I do this in the GUI via normal mode (i.e. the LED is lit) dfu-util starts working, but at the end when it says that the firmware was uploaded successfully the board reboots and the firmware hasn't actually been changed.

Normal flashing (not rescue flashing) does not involve dfu-util but uses the firmware/flasher binary.
Are you using a self compiled firmware/flasher binary? Normally normal flashing first uploads the firmware image to sdram, then uploads the firmware/flasher binary (as if it was a compiled patch), executes this binary. At this point the usb connection is lost, the firmware flasher takes over the normal firmware duties, green led stays on, the red led blinks during flash erase and programming, and then the board reboots into the new firmware.
Sounds like your firmware/flasher binary is invalid similar like your compiler produces an invalid firmware, so nothing is flashed.

[rekado]

Sounds like your firmware/flasher binary is invalid similar like your compiler produces an invalid firmware, so nothing is flashed.

Yes, this explains it. I confirmed that using the prebuilt flasher.bin the board accepts the broken firmware and behaves in the same manner.

I have tried many combinations of cross-compiler versions, newlib vs newlib-nano, binutils, etc, but haven't been able to identify the source of these problems yet. For now I'll use the precompiled binaries for flasher, mounter, and axoloti, but I'd really like to eventually be able to use the binaries I compile myself.

It would be nice if there was a minimal binary I could compare -- even flasher.{elf,bin} is much too large to allow me to compare the two compilers.

[johannes]

It would be nice if there was a minimal binary I could compare -- even flasher.{elf,bin} is much too large to allow me to compare the two compilers.

I recommend comparing the disassembly annotated with sourcecode of the .elf with arm-none-eabi-objdump. The ResetHandler would be the first thing to look at. I can't be of further help here as it drains time away from more important issues, and this is way more related to building compilers than to axoloti itself. Maybe ask here?

[rekado]

I understand. Thank you for the hints and explanations so far! I think I can go on alone from here.

[rekado]

Another update for the record: the flasher and mounter binaries are now identical after making sure that newlib-nano is used as the C library instead of plain newlib. The difference between the two is the configure flags.

Unfortunately, the axoloti.elf file still differs (and doesn't work), but I'm getting closer to a package for GNU Guix, so all people would have to do is run guix package -i axoloti-patcher to install everything that's needed to use the board on any GNU+Linux system.

[rekado]

Success! I had to pass --enable-multilib to the build of the cross-compiler and newlib-nano. Now I have a working setup and a set of package expressions for Guix, which make it easy to install a self-contained environment for Axoloti.

I'll polish the package expressions a little and then publish and announce them.