BPI/sunxi-tools
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
sunxi-tools/thunks/fel-to-spl-thunk.S

163 lines
4.6 KiB
ArmAsm
Raw Normal View History

fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
/*
* Copyright © 2015 Siarhei Siamashka <siarhei.siamashka@gmail.com>
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*/
fel: thunks: Fix fel-to-spl-thunk to be ARMv5TE compatible Currently the thunk we upload into the SRAM is using DSB and ISB instructions, which were introduced in ARMv7. Also it relies on movw/movt pairs, which became available in ARMv6T2. The Allwinner F1Cx00 SoCs are using an ARMv5TE compliant core, so they do not know these instructions. Change the code to be ARMv5TE compliant, so it can run on all relevant Allwinner ARM cores: - One movw is just used to compare two bits, replace that with a tst/tsteq sequence to skip the load. - The other movw/movt pairs get replaced with ldr's, that load from literal storage at the end of the code (from Icenowy). - The DSB and ISB get replaced with their CP15 MCR counterparts. Those are deprecated in ARMv7, but still work, when the CP15BEN bit is set in SCTLR. We check for this in fel.c (from Icenowy). ISB is not implemented on the ARM926, so make this conditional. A simple branch takes care of the desired pipeline flush for the old SoC. Also remove the rather pointless Ruby prolog that generates the header file. We have a less awkward version of this in the Makefile, and need that for the other thunks there anyway, so it's just duplicated code. Embedding a header generator in Ruby in an assembly file is a cute gimmick, but serves no purpose anymore. This is based on work by Icenowy, who put a similar solution in a separate file. Originally-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Andre Przywara <osp@andrep.de>
2022-01-20 01:14:54 +00:00
.arm
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
BUF1 .req r0
BUF2 .req r1
TMP1 .req r2
TMP2 .req r3
SWAPTBL .req r4
FULLSIZE .req r5
BUFSIZE .req r6
CHECKSUM .req r7
fel: Make the SPL load address configurable instead of hardcoded 0x0 Add a new field 'spl_addr' to the SoC description structure and adjust the code to honor it. This is needed for supporting Allwinner A80. Tested on Allwinner A20 by changing the 'spl_addr' to 0x28000 in the 'fel' tool and using a custom build of U-Boot (CONFIG_SPL_TEXT_BASE changed from 0x20 to 0x28020). Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-08-19 14:41:56 +03:00
SPL_ADDR .req r8
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
entry_point:
b setup_stack
stack_begin:
fel: thunks: Fix fel-to-spl-thunk to be ARMv5TE compatible Currently the thunk we upload into the SRAM is using DSB and ISB instructions, which were introduced in ARMv7. Also it relies on movw/movt pairs, which became available in ARMv6T2. The Allwinner F1Cx00 SoCs are using an ARMv5TE compliant core, so they do not know these instructions. Change the code to be ARMv5TE compliant, so it can run on all relevant Allwinner ARM cores: - One movw is just used to compare two bits, replace that with a tst/tsteq sequence to skip the load. - The other movw/movt pairs get replaced with ldr's, that load from literal storage at the end of the code (from Icenowy). - The DSB and ISB get replaced with their CP15 MCR counterparts. Those are deprecated in ARMv7, but still work, when the CP15BEN bit is set in SCTLR. We check for this in fel.c (from Icenowy). ISB is not implemented on the ARM926, so make this conditional. A simple branch takes care of the desired pipeline flush for the old SoC. Also remove the rather pointless Ruby prolog that generates the header file. We have a less awkward version of this in the Makefile, and need that for the other thunks there anyway, so it's just duplicated code. Embedding a header generator in Ruby in an assembly file is a cute gimmick, but serves no purpose anymore. This is based on work by Icenowy, who put a similar solution in a separate file. Originally-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Andre Przywara <osp@andrep.de>
2022-01-20 01:14:54 +00:00
.space 32, 0xff
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
stack_end:
nop
/* A function, which walks the table and swaps all buffers */
swap_all_buffers:
fel: Make the SPL load address configurable instead of hardcoded 0x0 Add a new field 'spl_addr' to the SoC description structure and adjust the code to honor it. This is needed for supporting Allwinner A80. Tested on Allwinner A20 by changing the 'spl_addr' to 0x28000 in the 'fel' tool and using a custom build of U-Boot (CONFIG_SPL_TEXT_BASE changed from 0x20 to 0x28020). Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-08-19 14:41:56 +03:00
adr SWAPTBL, appended_data + 4
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
swap_next_buffer:
ldr BUF1, [SWAPTBL], #4
ldr BUF2, [SWAPTBL], #4
ldr BUFSIZE, [SWAPTBL], #4
cmp BUFSIZE, #0
bxeq lr
swap_next_word:
ldr TMP1, [BUF1]
ldr TMP2, [BUF2]
subs BUFSIZE, BUFSIZE, #4
str TMP1, [BUF2], #4
str TMP2, [BUF1], #4
bne swap_next_word
b swap_next_buffer
setup_stack: /* Save the original SP, LR and CPSR to stack */
fel: Make the SPL load address configurable instead of hardcoded 0x0 Add a new field 'spl_addr' to the SoC description structure and adjust the code to honor it. This is needed for supporting Allwinner A80. Tested on Allwinner A20 by changing the 'spl_addr' to 0x28000 in the 'fel' tool and using a custom build of U-Boot (CONFIG_SPL_TEXT_BASE changed from 0x20 to 0x28020). Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-08-19 14:41:56 +03:00
ldr SPL_ADDR, appended_data
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
adr BUF1, stack_end
str sp, [BUF1, #-4]!
mov sp, BUF1
mrs TMP1, cpsr
push {TMP1, lr}
/* Disable IRQ and FIQ */
orr TMP1, #0xc0
msr cpsr_c, TMP1
/* Check if the instructions or data cache is enabled */
mrc p15, 0, TMP1, c1, c0, 0
fel: thunks: Fix fel-to-spl-thunk to be ARMv5TE compatible Currently the thunk we upload into the SRAM is using DSB and ISB instructions, which were introduced in ARMv7. Also it relies on movw/movt pairs, which became available in ARMv6T2. The Allwinner F1Cx00 SoCs are using an ARMv5TE compliant core, so they do not know these instructions. Change the code to be ARMv5TE compliant, so it can run on all relevant Allwinner ARM cores: - One movw is just used to compare two bits, replace that with a tst/tsteq sequence to skip the load. - The other movw/movt pairs get replaced with ldr's, that load from literal storage at the end of the code (from Icenowy). - The DSB and ISB get replaced with their CP15 MCR counterparts. Those are deprecated in ARMv7, but still work, when the CP15BEN bit is set in SCTLR. We check for this in fel.c (from Icenowy). ISB is not implemented on the ARM926, so make this conditional. A simple branch takes care of the desired pipeline flush for the old SoC. Also remove the rather pointless Ruby prolog that generates the header file. We have a less awkward version of this in the Makefile, and need that for the other thunks there anyway, so it's just duplicated code. Embedding a header generator in Ruby in an assembly file is a cute gimmick, but serves no purpose anymore. This is based on work by Icenowy, who put a similar solution in a separate file. Originally-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Andre Przywara <osp@andrep.de>
2022-01-20 01:14:54 +00:00
tst TMP1, #(1 << 2)
tsteq TMP1, #(1 << 12)
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
bne cache_is_unsupported
bl swap_all_buffers
verify_checksum:
fel: thunks: Fix fel-to-spl-thunk to be ARMv5TE compatible Currently the thunk we upload into the SRAM is using DSB and ISB instructions, which were introduced in ARMv7. Also it relies on movw/movt pairs, which became available in ARMv6T2. The Allwinner F1Cx00 SoCs are using an ARMv5TE compliant core, so they do not know these instructions. Change the code to be ARMv5TE compliant, so it can run on all relevant Allwinner ARM cores: - One movw is just used to compare two bits, replace that with a tst/tsteq sequence to skip the load. - The other movw/movt pairs get replaced with ldr's, that load from literal storage at the end of the code (from Icenowy). - The DSB and ISB get replaced with their CP15 MCR counterparts. Those are deprecated in ARMv7, but still work, when the CP15BEN bit is set in SCTLR. We check for this in fel.c (from Icenowy). ISB is not implemented on the ARM926, so make this conditional. A simple branch takes care of the desired pipeline flush for the old SoC. Also remove the rather pointless Ruby prolog that generates the header file. We have a less awkward version of this in the Makefile, and need that for the other thunks there anyway, so it's just duplicated code. Embedding a header generator in Ruby in an assembly file is a cute gimmick, but serves no purpose anymore. This is based on work by Icenowy, who put a similar solution in a separate file. Originally-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Andre Przywara <osp@andrep.de>
2022-01-20 01:14:54 +00:00
ldr CHECKSUM, checksum_seed
fel: Make the SPL load address configurable instead of hardcoded 0x0 Add a new field 'spl_addr' to the SoC description structure and adjust the code to honor it. This is needed for supporting Allwinner A80. Tested on Allwinner A20 by changing the 'spl_addr' to 0x28000 in the 'fel' tool and using a custom build of U-Boot (CONFIG_SPL_TEXT_BASE changed from 0x20 to 0x28020). Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-08-19 14:41:56 +03:00
mov BUF1, SPL_ADDR
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
ldr FULLSIZE, [BUF1, #16]
check_next_word:
ldr TMP1, [BUF1], #4
subs FULLSIZE, FULLSIZE, #4
add CHECKSUM, CHECKSUM, TMP1
bne check_next_word
fel: Make the SPL load address configurable instead of hardcoded 0x0 Add a new field 'spl_addr' to the SoC description structure and adjust the code to honor it. This is needed for supporting Allwinner A80. Tested on Allwinner A20 by changing the 'spl_addr' to 0x28000 in the 'fel' tool and using a custom build of U-Boot (CONFIG_SPL_TEXT_BASE changed from 0x20 to 0x28020). Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-08-19 14:41:56 +03:00
ldr TMP1, [SPL_ADDR, #12]
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
subs CHECKSUM, CHECKSUM, TMP1, lsl #1
bne checksum_is_bad
/* Change 'eGON.BT0' -> 'eGON.FEL' */
fel: thunks: Fix fel-to-spl-thunk to be ARMv5TE compatible Currently the thunk we upload into the SRAM is using DSB and ISB instructions, which were introduced in ARMv7. Also it relies on movw/movt pairs, which became available in ARMv6T2. The Allwinner F1Cx00 SoCs are using an ARMv5TE compliant core, so they do not know these instructions. Change the code to be ARMv5TE compliant, so it can run on all relevant Allwinner ARM cores: - One movw is just used to compare two bits, replace that with a tst/tsteq sequence to skip the load. - The other movw/movt pairs get replaced with ldr's, that load from literal storage at the end of the code (from Icenowy). - The DSB and ISB get replaced with their CP15 MCR counterparts. Those are deprecated in ARMv7, but still work, when the CP15BEN bit is set in SCTLR. We check for this in fel.c (from Icenowy). ISB is not implemented on the ARM926, so make this conditional. A simple branch takes care of the desired pipeline flush for the old SoC. Also remove the rather pointless Ruby prolog that generates the header file. We have a less awkward version of this in the Makefile, and need that for the other thunks there anyway, so it's just duplicated code. Embedding a header generator in Ruby in an assembly file is a cute gimmick, but serves no purpose anymore. This is based on work by Icenowy, who put a similar solution in a separate file. Originally-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Andre Przywara <osp@andrep.de>
2022-01-20 01:14:54 +00:00
ldr TMP1, egon_fel_str
fel: Make the SPL load address configurable instead of hardcoded 0x0 Add a new field 'spl_addr' to the SoC description structure and adjust the code to honor it. This is needed for supporting Allwinner A80. Tested on Allwinner A20 by changing the 'spl_addr' to 0x28000 in the 'fel' tool and using a custom build of U-Boot (CONFIG_SPL_TEXT_BASE changed from 0x20 to 0x28020). Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-08-19 14:41:56 +03:00
str TMP1, [SPL_ADDR, #8]
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
fel: thunks: Fix fel-to-spl-thunk to be ARMv5TE compatible Currently the thunk we upload into the SRAM is using DSB and ISB instructions, which were introduced in ARMv7. Also it relies on movw/movt pairs, which became available in ARMv6T2. The Allwinner F1Cx00 SoCs are using an ARMv5TE compliant core, so they do not know these instructions. Change the code to be ARMv5TE compliant, so it can run on all relevant Allwinner ARM cores: - One movw is just used to compare two bits, replace that with a tst/tsteq sequence to skip the load. - The other movw/movt pairs get replaced with ldr's, that load from literal storage at the end of the code (from Icenowy). - The DSB and ISB get replaced with their CP15 MCR counterparts. Those are deprecated in ARMv7, but still work, when the CP15BEN bit is set in SCTLR. We check for this in fel.c (from Icenowy). ISB is not implemented on the ARM926, so make this conditional. A simple branch takes care of the desired pipeline flush for the old SoC. Also remove the rather pointless Ruby prolog that generates the header file. We have a less awkward version of this in the Makefile, and need that for the other thunks there anyway, so it's just duplicated code. Embedding a header generator in Ruby in an assembly file is a cute gimmick, but serves no purpose anymore. This is based on work by Icenowy, who put a similar solution in a separate file. Originally-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Andre Przywara <osp@andrep.de>
2022-01-20 01:14:54 +00:00
/*
* Call the SPL code, but before that make sure the CPU sees the
* recently uploaded code. This requires a DSB and ISB.
* The "dsb" and "isb" *instructions* are not available in ARMv5TE,
* but at least for DSB we can use the CP15 register encoding. This
* works for ARMv7 and v8 as well, because we have checked our SCTLR
* before (in fel.c), so we know that CP15BEN is set.
* The ARM926 core does not implement ISB, instead the TRM recommends
* just a branch to achieve the same "flush the pipeline" effect.
* As just this is not sufficient for later cores, check the MIDR
* register, and do the DSB only for ARMv6 or later.
* The input register for the CP15 instruction is ignored.
*/
mcr p15, 0, TMP1, c7, c10, 4 /* CP15DSB */
mrc p15, 0, TMP1, c0, c0, 0 /* read MIDR */
and TMP1, TMP1, #(0xf << 16) /* architecture */
cmp TMP1, #(0x6 << 16) /* ARMv5TEJ */
mcrgt p15, 0, TMP1, c7, c5, 4 /* CP15ISB, if > ARMv5TEJ */
fel: Make the SPL load address configurable instead of hardcoded 0x0 Add a new field 'spl_addr' to the SoC description structure and adjust the code to honor it. This is needed for supporting Allwinner A80. Tested on Allwinner A20 by changing the 'spl_addr' to 0x28000 in the 'fel' tool and using a custom build of U-Boot (CONFIG_SPL_TEXT_BASE changed from 0x20 to 0x28020). Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-08-19 14:41:56 +03:00
blx SPL_ADDR
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
/* Return back to FEL */
b return_to_fel
cache_is_unsupported:
/* Bail out if cache is enabled and change 'eGON.BT0' -> 'eGON.???' */
fel: thunks: Fix fel-to-spl-thunk to be ARMv5TE compatible Currently the thunk we upload into the SRAM is using DSB and ISB instructions, which were introduced in ARMv7. Also it relies on movw/movt pairs, which became available in ARMv6T2. The Allwinner F1Cx00 SoCs are using an ARMv5TE compliant core, so they do not know these instructions. Change the code to be ARMv5TE compliant, so it can run on all relevant Allwinner ARM cores: - One movw is just used to compare two bits, replace that with a tst/tsteq sequence to skip the load. - The other movw/movt pairs get replaced with ldr's, that load from literal storage at the end of the code (from Icenowy). - The DSB and ISB get replaced with their CP15 MCR counterparts. Those are deprecated in ARMv7, but still work, when the CP15BEN bit is set in SCTLR. We check for this in fel.c (from Icenowy). ISB is not implemented on the ARM926, so make this conditional. A simple branch takes care of the desired pipeline flush for the old SoC. Also remove the rather pointless Ruby prolog that generates the header file. We have a less awkward version of this in the Makefile, and need that for the other thunks there anyway, so it's just duplicated code. Embedding a header generator in Ruby in an assembly file is a cute gimmick, but serves no purpose anymore. This is based on work by Icenowy, who put a similar solution in a separate file. Originally-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Andre Przywara <osp@andrep.de>
2022-01-20 01:14:54 +00:00
ldr TMP1, cache_enabled_str
fel: Make the SPL load address configurable instead of hardcoded 0x0 Add a new field 'spl_addr' to the SoC description structure and adjust the code to honor it. This is needed for supporting Allwinner A80. Tested on Allwinner A20 by changing the 'spl_addr' to 0x28000 in the 'fel' tool and using a custom build of U-Boot (CONFIG_SPL_TEXT_BASE changed from 0x20 to 0x28020). Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-08-19 14:41:56 +03:00
str TMP1, [SPL_ADDR, #8]
fel-to-spl-thunk.S: Fix safety guard which checks for enabled cache The exit code path after detecting that the cache is enabled does not need to swap FEL stacks and backup buffers. This way we get the error actually reported by the 'fel' tool instead of the device getting locked up. The thunk code refuses to work if the caches are enabled because we don't want to deal with the instructions/data cache coherency yet. The caches are initially in a disabled state upon activating FEL mode on all currently known Allwinner processors. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-08-19 14:25:46 +03:00
b return_to_fel_noswap
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
checksum_is_bad:
/* The checksum test failed, so change 'eGON.BT0' -> 'eGON.BAD' */
fel: thunks: Fix fel-to-spl-thunk to be ARMv5TE compatible Currently the thunk we upload into the SRAM is using DSB and ISB instructions, which were introduced in ARMv7. Also it relies on movw/movt pairs, which became available in ARMv6T2. The Allwinner F1Cx00 SoCs are using an ARMv5TE compliant core, so they do not know these instructions. Change the code to be ARMv5TE compliant, so it can run on all relevant Allwinner ARM cores: - One movw is just used to compare two bits, replace that with a tst/tsteq sequence to skip the load. - The other movw/movt pairs get replaced with ldr's, that load from literal storage at the end of the code (from Icenowy). - The DSB and ISB get replaced with their CP15 MCR counterparts. Those are deprecated in ARMv7, but still work, when the CP15BEN bit is set in SCTLR. We check for this in fel.c (from Icenowy). ISB is not implemented on the ARM926, so make this conditional. A simple branch takes care of the desired pipeline flush for the old SoC. Also remove the rather pointless Ruby prolog that generates the header file. We have a less awkward version of this in the Makefile, and need that for the other thunks there anyway, so it's just duplicated code. Embedding a header generator in Ruby in an assembly file is a cute gimmick, but serves no purpose anymore. This is based on work by Icenowy, who put a similar solution in a separate file. Originally-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Andre Przywara <osp@andrep.de>
2022-01-20 01:14:54 +00:00
ldr TMP1, checksum_failed_str
fel: Make the SPL load address configurable instead of hardcoded 0x0 Add a new field 'spl_addr' to the SoC description structure and adjust the code to honor it. This is needed for supporting Allwinner A80. Tested on Allwinner A20 by changing the 'spl_addr' to 0x28000 in the 'fel' tool and using a custom build of U-Boot (CONFIG_SPL_TEXT_BASE changed from 0x20 to 0x28020). Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-08-19 14:41:56 +03:00
str TMP1, [SPL_ADDR, #8]
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
return_to_fel:
bl swap_all_buffers
fel-to-spl-thunk.S: Fix safety guard which checks for enabled cache The exit code path after detecting that the cache is enabled does not need to swap FEL stacks and backup buffers. This way we get the error actually reported by the 'fel' tool instead of the device getting locked up. The thunk code refuses to work if the caches are enabled because we don't want to deal with the instructions/data cache coherency yet. The caches are initially in a disabled state upon activating FEL mode on all currently known Allwinner processors. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-08-19 14:25:46 +03:00
return_to_fel_noswap:
fel: New command for loading U-Boot SPL binaries in eGON format Now it is possible to load and execute the same U-Boot SPL, as used for booting from SD cards. Just a different delivery method (a USB OTG cable instead of an SD card) for handling exactly the same content. The only argument for this new command is the name of the SPL binary file (with a eGON header generated by the 'mksunxiboot' tool). Now the 'fel' tool can be run as: fel spl u-boot-sunxi-with-spl.bin Before this change, the SPL was only able to use the memory between addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB. This is the biggest contiguous area in SRAM, which is not used by the FEL code from the BROM. Unfortunately, it is rather small. And also the unusual starting offset was making it difficult to use the same SPL binary for booting from the SD card and via FEL. There are surely more unused parts of SRAM, but they are scattered across multiple locations, primarily because the FEL code from the BROM sets up two stacks at inconvenient locations (the IRQ handler stack at 0x2000, and a regular stack at 0x7000). Essentially, the problem to solve here is to ensure a sufficiently large and consistent SRAM address space for the SPL without any potentially SoC specific holes in the case of booting over USB via FEL. This is achieved by injecting special entry/exit thunk code, which is moving the data in SRAM to provide a contiguous space for the SPL at the beginning of SRAM, while still preserving the the data from the BROM elsewhere. When the SPL tries to return control back to the FEL code in the BROM, the thunk code moves the data back to its original place. Additionally, the eGON checksum is verified to ensure that no data corruption has happened due to some unexpected clash with the FEL protocol code from the BROM. So the thunk code takes care of the address space allocation uglyness and provides the U-Boot SPL with a somewhat nicer abstraction. Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of SRAM because the BROM data is saved to different SRAM section. There is also generic code, which does not rely on extra SRAM sections, but just glues together the unused free space from both BROM FEL stacks to provide something like ~21 KiB to the SPL. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
pop {TMP1, lr}
msr cpsr_c, TMP1 /* Restore the original CPSR */
ldr sp, [sp]
bx lr
fel: thunks: Fix fel-to-spl-thunk to be ARMv5TE compatible Currently the thunk we upload into the SRAM is using DSB and ISB instructions, which were introduced in ARMv7. Also it relies on movw/movt pairs, which became available in ARMv6T2. The Allwinner F1Cx00 SoCs are using an ARMv5TE compliant core, so they do not know these instructions. Change the code to be ARMv5TE compliant, so it can run on all relevant Allwinner ARM cores: - One movw is just used to compare two bits, replace that with a tst/tsteq sequence to skip the load. - The other movw/movt pairs get replaced with ldr's, that load from literal storage at the end of the code (from Icenowy). - The DSB and ISB get replaced with their CP15 MCR counterparts. Those are deprecated in ARMv7, but still work, when the CP15BEN bit is set in SCTLR. We check for this in fel.c (from Icenowy). ISB is not implemented on the ARM926, so make this conditional. A simple branch takes care of the desired pipeline flush for the old SoC. Also remove the rather pointless Ruby prolog that generates the header file. We have a less awkward version of this in the Makefile, and need that for the other thunks there anyway, so it's just duplicated code. Embedding a header generator in Ruby in an assembly file is a cute gimmick, but serves no purpose anymore. This is based on work by Icenowy, who put a similar solution in a separate file. Originally-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Andre Przywara <osp@andrep.de>
2022-01-20 01:14:54 +00:00
checksum_seed:
.word 0x5f0a6c39
egon_fel_str:
.ascii ".FEL"
cache_enabled_str:
.ascii ".???"
checksum_failed_str:
.ascii ".BAD"
fel: Make the SPL load address configurable instead of hardcoded 0x0 Add a new field 'spl_addr' to the SoC description structure and adjust the code to honor it. This is needed for supporting Allwinner A80. Tested on Allwinner A20 by changing the 'spl_addr' to 0x28000 in the 'fel' tool and using a custom build of U-Boot (CONFIG_SPL_TEXT_BASE changed from 0x20 to 0x28020). Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-08-19 14:41:56 +03:00
appended_data:
/*
* The appended data uses the following format:
*
* struct {
* uint32_t spl_addr;
* sram_swap_buffers swaptbl[];
* };
*
* More details about the 'spl_addr' variable and the 'sram_swap_buffers'
* struct can be found in the 'fel.c' source file.
*/
Reference in New Issue Copy Permalink