rockchip: back-to-bootrom: replace assembly-implementation with C-code

The previous setjmp-implementation (as a static inline function that contained an 'asm volatile' sequence) was extremely fragile: (some versions of) GCC optimised the set of registers. One critical example was the removal of 'r9' from the clobber list, if -ffixed-reg9 was supplied.

To increase robustness and ensure PCS-compliant behaviour, the setjmp and longjmp implementation are now in assembly and closely match what one would expect to find in a libc implementation.

Recent discussions confirmed (what the code always assumed): the Rockchip BROM always enters U-Boot with the stack-pointer valid (i.e. the U-Boot startup code is running off the BROM stack).

We can thus replace the back-to-bootrom code (i.e. both the save_boot_params and back_to_bootrom implementations) using C-code based on setjmp/longjmp. The new implementation is already structured to allow an easy drop-in of Andy's changes to enter download-mode when returning to the BROM.

This turned out to require a some tweaking to system.h (making sure that the prototype for save_boot_params_ret is visible for A64)and start.S (so binutils knows that this is a possible function entry and it can correctly insert A32-to-Thumb transitions) and taking the axe to setjmp.h (which created quite a few issues with it not expecting A32/T32/Thumb call-sites and some fragility from GCC being smart about the clobber-list of the inline assembly... which led to r9 not being saved or restored).

Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:

Quoted 11 lines

Recent discussions confirmed (what the code always assumed): the Rockchip BROM always enters U-Boot with the stack-pointer valid (i.e. the U-Boot startup code is running off the BROM stack).

We can thus replace the back-to-bootrom code (i.e. both the save_boot_params and back_to_bootrom implementations) using C-code based on setjmp/longjmp. The new implementation is already structured to allow an easy drop-in of Andy's changes to enter download-mode when returning to the BROM.

Quoted 8 lines

This turned out to require a some tweaking to system.h (making sure that the prototype for save_boot_params_ret is visible for A64)and start.S (so binutils knows that this is a possible function entry and it can correctly insert A32-to-Thumb transitions) and taking the axe to setjmp.h (which created quite a few issues with it not expecting A32/T32/Thumb call-sites and some fragility from GCC being smart about the clobber-list of the inline assembly... which led to r9 not being saved or restored).

This is missing information on dependant series. Using the u-boot-rockchip repository which is at
782088de7be7 ("rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs")

patches 1-3 apply, but patch 4 fails to apply as I seem to be missing some dependencies.

And the u-boot mailinglist seems to be configured very strangely, as it seems to rip apart patch-series only sending me some parts.

So far I can at least say, that the u-boot-rockchip repo at the above commit still boots. Could you please point me to mbox versions of needed base patches?

Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:

Quoted 28 lines

Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:

Quoted 11 lines

Recent discussions confirmed (what the code always assumed): the Rockchip BROM always enters U-Boot with the stack-pointer valid (i.e. the U-Boot startup code is running off the BROM stack).

We can thus replace the back-to-bootrom code (i.e. both the save_boot_params and back_to_bootrom implementations) using C-code based on setjmp/longjmp. The new implementation is already structured to allow an easy drop-in of Andy's changes to enter download-mode when returning to the BROM.

Quoted 8 lines

This turned out to require a some tweaking to system.h (making sure that the prototype for save_boot_params_ret is visible for A64)and start.S (so binutils knows that this is a possible function entry and it can correctly insert A32-to-Thumb transitions) and taking the axe to setjmp.h (which created quite a few issues with it not expecting A32/T32/Thumb call-sites and some fragility from GCC being smart about the clobber-list of the inline assembly... which led to r9 not being saved or restored).

This is missing information on dependant series. Using the u-boot-rockchip repository which is at
782088de7be7 ("rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs")

patches 1-3 apply, but patch 4 fails to apply as I seem to be missing some dependencies.

Quoted 6 lines

And the u-boot mailinglist seems to be configured very strangely, as it seems to rip apart patch-series only sending me some parts.

So far I can at least say, that the u-boot-rockchip repo at the above commit still boots. Could you please point me to mbox versions of needed base patches?

Also, with patches 1-3 and 5 applied the radxarock board fails to start. I see the SPL banner and a "Returning to boot ROM..." and then nothing.

I do belive it may have something to do with the TPL's + SPL's stack both being at the end of SRAM? Having the SPL go back to TPL and then back to bootrom was my original intention as well, but didn't work at the time.

Quoted 40 lines · On 21 Sep 2017, at 11:44, Heiko Stuebner <heiko at sntech.de…

Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:

Quoted 28 lines

Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:

Quoted 11 lines

Recent discussions confirmed (what the code always assumed): the Rockchip BROM always enters U-Boot with the stack-pointer valid (i.e. the U-Boot startup code is running off the BROM stack).

We can thus replace the back-to-bootrom code (i.e. both the save_boot_params and back_to_bootrom implementations) using C-code based on setjmp/longjmp. The new implementation is already structured to allow an easy drop-in of Andy's changes to enter download-mode when returning to the BROM.

Quoted 8 lines

This turned out to require a some tweaking to system.h (making sure that the prototype for save_boot_params_ret is visible for A64)and start.S (so binutils knows that this is a possible function entry and it can correctly insert A32-to-Thumb transitions) and taking the axe to setjmp.h (which created quite a few issues with it not expecting A32/T32/Thumb call-sites and some fragility from GCC being smart about the clobber-list of the inline assembly... which led to r9 not being saved or restored).

This is missing information on dependant series. Using the u-boot-rockchip repository which is at
782088de7be7 ("rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs")

patches 1-3 apply, but patch 4 fails to apply as I seem to be missing some dependencies.

Quoted 6 lines

And the u-boot mailinglist seems to be configured very strangely, as it seems to rip apart patch-series only sending me some parts.

So far I can at least say, that the u-boot-rockchip repo at the above commit still boots. Could you please point me to mbox versions of needed base patches?

Quoted 7 lines

Also, with patches 1-3 and 5 applied the radxarock board fails to start. I see the SPL banner and a "Returning to boot ROM..." and then nothing.

I do belive it may have something to do with the TPL's + SPL's stack both being at the end of SRAM? Having the SPL go back to TPL and then back to bootrom was my original intention as well, but didn't work at the time.

I didn’t expect the stacks to overlap… so returning from SPL to TPL can’t work. However, the jump_to_spl() is at least partially to blame (we already have a working C-runtime and there’s no point in reentering through the reset entry-point).

I need to ponder this a bit, but my gut feeling is that the TPL->SPL transition can be done in a less intrusive way and may allow us to retain the TPL stack.

Quoted 40 lines · Heiko Stuebner

Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:

Quoted 30 lines

Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:

Quoted 10 lines

Recent discussions confirmed (what the code always assumed): the Rockchip BROM always enters U-Boot with the stack-pointer valid (i.e. the U-Boot startup code is running off the BROM stack).

We can thus replace the back-to-bootrom code (i.e. both the save_boot_params and back_to_bootrom implementations) using C-code based on setjmp/longjmp. The new implementation is already structured to allow an easy drop-in of Andy's changes to enter download-mode when returning to the BROM.

Quoted 8 lines

This turned out to require a some tweaking to system.h (making sure that the prototype for save_boot_params_ret is visible for A64)and start.S (so binutils knows that this is a possible function entry and it can correctly insert A32-to-Thumb transitions) and taking the axe to setjmp.h (which created quite a few issues with it not expecting A32/T32/Thumb call-sites and some fragility from GCC being smart about the clobber-list of the inline assembly... which led to r9 not being saved or restored).

This is missing information on dependant series. Using the u-boot-rockchip
repository which is at
782088de7be7 ("rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs")

patches 1-3 apply, but patch 4 fails to apply as I seem to be missing some
dependencies.

Quoted 6 lines

And the u-boot mailinglist seems to be configured very strangely, as it seems to rip apart patch-series only sending me some parts.

So far I can at least say, that the u-boot-rockchip repo at the above commit still boots. Could you please point me to mbox versions of needed base patches?

Quoted 7 lines

Also, with patches 1-3 and 5 applied the radxarock board fails to start. I see the SPL banner and a "Returning to boot ROM..." and then nothing.

I do belive it may have something to do with the TPL's + SPL's stack both being at the end of SRAM? Having the SPL go back to TPL and then back to bootrom was my original intention as well, but didn't work at the time.

I didn’t expect the stacks to overlap… so returning from SPL to TPL can’t work. However, the jump_to_spl() is at least partially to blame (we already have a working C-runtime and there’s no point in reentering through the reset entry-point).

I need to ponder this a bit, but my gut feeling is that the TPL->SPL transition can be done in a less intrusive way and may allow us to retain the TPL stack.

Am Donnerstag, 21. September 2017, 12:25:17 CEST schrieb Dr. Philipp Tomsich:

Quoted 45 lines

Quoted 38 lines · Heiko Stuebner

Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:

Quoted 29 lines

Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:

Quoted 10 lines

Recent discussions confirmed (what the code always assumed): the Rockchip BROM always enters U-Boot with the stack-pointer valid (i.e. the U-Boot startup code is running off the BROM stack).

We can thus replace the back-to-bootrom code (i.e. both the save_boot_params and back_to_bootrom implementations) using C-code based on setjmp/longjmp. The new implementation is already structured to allow an easy drop-in of Andy's changes to enter download-mode when returning to the BROM.

Quoted 8 lines

This turned out to require a some tweaking to system.h (making sure that the prototype for save_boot_params_ret is visible for A64)and start.S (so binutils knows that this is a possible function entry and it can correctly insert A32-to-Thumb transitions) and taking the axe to setjmp.h (which created quite a few issues with it not expecting A32/T32/Thumb call-sites and some fragility from GCC being smart about the clobber-list of the inline assembly... which led to r9 not being saved or restored).

This is missing information on dependant series. Using the u-boot-rockchip
repository which is at
782088de7be7 ("rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs")

patches 1-3 apply, but patch 4 fails to apply as I seem to be missing some
dependencies.

Quoted 6 lines

And the u-boot mailinglist seems to be configured very strangely, as it seems to rip apart patch-series only sending me some parts.

So far I can at least say, that the u-boot-rockchip repo at the above commit still boots. Could you please point me to mbox versions of needed base patches?

Quoted 7 lines

Also, with patches 1-3 and 5 applied the radxarock board fails to start. I see the SPL banner and a "Returning to boot ROM..." and then nothing.

I do belive it may have something to do with the TPL's + SPL's stack both being at the end of SRAM? Having the SPL go back to TPL and then back to bootrom was my original intention as well, but didn't work at the time.

Quoted 8 lines

I didn’t expect the stacks to overlap… so returning from SPL to TPL can’t work. However, the jump_to_spl() is at least partially to blame (we already have a working C-runtime and there’s no point in reentering through the reset entry-point).

I need to ponder this a bit, but my gut feeling is that the TPL->SPL transition can be done in a less intrusive way and may allow us to retain the TPL stack.

Alternatively, if you can think of an easier solution we could do away with the TPL in its current form. When I did the rk3188 support, this looked like the least-messy way to me, but it really only does the one jump back to the bootrom - so I'm not sure if there isn't simply an easier solution.

And for example the (still wip?) rk3066 series did use spl+tpl in a different way due to bootrom-nand-limitations. rk3066 and rk3188 are quite similar with the rk3066 simply not having the sd-boot capability, so if we want to have nand-boot on rk3188 as well in the future, this may need a different rework again.

Heiko

Hi Philipp, Heiko:

I finally got the upstream u-boot run on a rk3188 board which can be attached by DS5 debugger,

if you have some registers info want to check, please let me know.

Quoted 70 lines · Heiko Stübner

Am Donnerstag, 21. September 2017, 12:25:17 CEST schrieb Dr. Philipp Tomsich:

Quoted 45 lines

Quoted 38 lines · Heiko Stuebner

Am Donnerstag, 21. September 2017, 11:09:49 CEST schrieb Heiko Stuebner:

Quoted 29 lines

Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:

Quoted 10 lines

Recent discussions confirmed (what the code always assumed): the Rockchip BROM always enters U-Boot with the stack-pointer valid (i.e. the U-Boot startup code is running off the BROM stack).

We can thus replace the back-to-bootrom code (i.e. both the save_boot_params and back_to_bootrom implementations) using C-code based on setjmp/longjmp. The new implementation is already structured to allow an easy drop-in of Andy's changes to enter download-mode when returning to the BROM.

Quoted 8 lines

This turned out to require a some tweaking to system.h (making sure that the prototype for save_boot_params_ret is visible for A64)and start.S (so binutils knows that this is a possible function entry and it can correctly insert A32-to-Thumb transitions) and taking the axe to setjmp.h (which created quite a few issues with it not expecting A32/T32/Thumb call-sites and some fragility from GCC being smart about the clobber-list of the inline assembly... which led to r9 not being saved or restored).

This is missing information on dependant series. Using the u-boot-rockchip
repository which is at
782088de7be7 ("rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs")

patches 1-3 apply, but patch 4 fails to apply as I seem to be missing some
dependencies.

Quoted 6 lines

And the u-boot mailinglist seems to be configured very strangely, as it seems to rip apart patch-series only sending me some parts.

So far I can at least say, that the u-boot-rockchip repo at the above commit still boots. Could you please point me to mbox versions of needed base patches?

Quoted 7 lines

Also, with patches 1-3 and 5 applied the radxarock board fails to start. I see the SPL banner and a "Returning to boot ROM..." and then nothing.

I do belive it may have something to do with the TPL's + SPL's stack both being at the end of SRAM? Having the SPL go back to TPL and then back to bootrom was my original intention as well, but didn't work at the time.

Quoted 8 lines

I didn’t expect the stacks to overlap… so returning from SPL to TPL can’t work. However, the jump_to_spl() is at least partially to blame (we already have a working C-runtime and there’s no point in reentering through the reset entry-point).

I need to ponder this a bit, but my gut feeling is that the TPL->SPL transition can be done in a less intrusive way and may allow us to retain the TPL stack.

Alternatively, if you can think of an easier solution we could do away with the TPL in its current form. When I did the rk3188 support, this looked like the least-messy way to me, but it really only does the one jump back to the bootrom - so I'm not sure if there isn't simply an easier solution.

And for example the (still wip?) rk3066 series did use spl+tpl in a different way due to bootrom-nand-limitations. rk3066 and rk3188 are quite similar with the rk3066 simply not having the sd-boot capability, so if we want to have nand-boot on rk3188 as well in the future, this may need a different rework again.

Heiko

Am Donnerstag, 21. September 2017, 10:19:23 CEST schrieb Philipp Tomsich:

Quoted 11 lines

Recent discussions confirmed (what the code always assumed): the Rockchip BROM always enters U-Boot with the stack-pointer valid (i.e. the U-Boot startup code is running off the BROM stack).

We can thus replace the back-to-bootrom code (i.e. both the save_boot_params and back_to_bootrom implementations) using C-code based on setjmp/longjmp. The new implementation is already structured to allow an easy drop-in of Andy's changes to enter download-mode when returning to the BROM.

Quoted 8 lines

This turned out to require a some tweaking to system.h (making sure that the prototype for save_boot_params_ret is visible for A64)and start.S (so binutils knows that this is a possible function entry and it can correctly insert A32-to-Thumb transitions) and taking the axe to setjmp.h (which created quite a few issues with it not expecting A32/T32/Thumb call-sites and some fragility from GCC being smart about the clobber-list of the inline assembly... which led to r9 not being saved or restored).

This is missing information on dependant series. Using the u-boot-rockchip repository which is at
782088de7be7 ("rockchip: imply ADC and SARADC_ROCKCHIP on supported SoCs")

patches 1-3 apply, but patch 4 fails to apply as I seem to be missing some dependencies.

And the u-boot mailinglist seems to be configured very strangely, as it seems to rip apart patch-series only sending me some parts.

So far I can at least say, that the u-boot-rockchip repo at the above commit still boots. Could you please point me to mbox versions of needed base patches?