crt0.S: Do not clear XIP control registers except in bootloader mode

[jpf91]

When the bootloader executes an application from XIP, the startup code should not disable the XIP unit, otherwise the application will crash.

[stnolting]

@jpf91 in #317:

The application startup code clears all registers in the peripheral space. This disables the XIP unit, which is of course a problem if the application is executing from XIP.

[stnolting]

Nice fix! 👍 😉
But somehow this feels like a very application-specific "workaround".

I think this is a general problem - not limited to the XIP module. If you configure any IO/peripheral device in the bootloader and then jump to another executable, all the modifications will be lost as the other executable will re-run the IO reset loop in crt0.

Maybe it would be better to have a general "do or do not IO reset" switch for the start-up code. For example we could add something like this around the IO reset loop:

#ifndef NO_IO_RESET

__crt0_reset_io_loop:
  sw   zero, 0(x8)
  addi x8,   x8, 4
  bne  x8,   x9, __crt0_reset_io_loop

#endif

Then we can switch off the reset loop while invoking the makfile by defining NO_IO_RESET via the USER_FLAGS variable:

$ make USER_FLAGS+=-DNO_IO_RESET clean_all exe

What do you think about this? 🤔

---

@GideonZ maybe this is also interesting for you ;)

[jpf91]

What do you think about this?

Works for me as well :-) Not sure whether we'd have to reset the UART in the bootloader then though...

[stnolting]

Do you might want to update this PR (or open a new one)? 😉
I would take care of updating the documentation.

Not sure whether we'd have to reset the UART in the bootloader then though...

I am not sure what you mean here 😅
The UARTs would be always reset by crt0 (which in case of the bootloader would always do a full reset of all IO modules) and configured by the bootloader itself. If the actual application (that is called by the bootloader) requires a different UART configuration, it can just redo the setup.

[jpf91]

I am not sure what you mean here sweat_smile

I was just thinking that the bootloader uses the UART, so it stays initialized after the user application is started. But I guess that should not really matter. As you say, it will be reinitialized anyway when the application uses it.

Do you might want to update this PR (or open a new one)?

Sure. I'll have to delay this until tomorrow though.

By the way: What should be the default? Reset enabled or not enabled? Or maybe default to enabled for the bootloader and default to disabled for applications?

[stnolting]

Sure. I'll have to delay this until tomorrow though.

Thanks! 👍

By the way: What should be the default? Reset enabled or not enabled? Or maybe default to enabled for the bootloader and default to disabled for applications?

I think the default should be the current situation, so resetting IO is always enabled - unless it is explicitly disabled by the user.

[jpf91]

I've updated the PR as discussed. I also tested this with the hello_world example and it's working as expected.

Maybe it makes sense to include a note in the documentation that make clean_all needs to be run when initially starting to use this flag. this initially confused me slightly :-)

[stnolting]

I've updated the PR as discussed. I also tested this with the hello_world example and it's working as expected.

🚀

Maybe it makes sense to include a note in the documentation that make clean_all needs to be run when initially starting to use this flag. this initially confused me slightly :-)

clean_all removes all object files, which is required here because we need to recompile crt0. I thought this was obvious 😅 but I will add some notes to the documentation regarding this.

[jpf91]

I thought this was obvious

It kinda is, it was the first thing I've tried when make clean didn't work :-)