ARM: Rework vector table setup
The current vector table setup has some shortcomings. First of all currently the case when the high vectors are inside SDRAM (that is, SDRAM reaches the end of the address space) is not supported. In this case we create a secondary page table for the section containing the vectors which gets overwritten by the general SDRAM secondary page table entries creation afterwards. On ARMv7 and later the exception table setup can be improved: Here the vector table address is configurable in the VBAR register. We can use this register to skip remapping the vector table. With this patch we first try to use the VBAR register before doing something else. Also, when we have to use the high vectors we first try a request_sdram_region to test if the vector table memory is already mapped. While at it sprinkle some comments into the code. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
WIP_next-LS
master
next
stable/v2017.05
stable/v2017.06
stable/v2017.07
stable/v2017.11
stable/v2018.07
stable/v2018.09
stable/v2018.12
v2020.07.0
v2020.06.0
v2020.05.0
v2020.04.0
v2020.03.0
v2020.02.0
v2020.01.0
v2019.12.0
v2019.11.0
v2019.10.0
v2019.09.0
v2019.08.1
v2019.08.0
v2019.07.0
v2019.06.1
v2019.06.0
v2019.05.0
v2019.04.0
v2019.03.0
v2019.02.0
v2019.01.0
v2018.12.0
v2018.11.0
v2018.10.0
v2018.09.1
v2018.09.0
v2018.08.1
v2018.08.0
v2018.07.2
v2018.07.1
v2018.07.0
v2018.06.0
v2018.05.0
v2018.04.0
v2018.03.0
v2018.02.0
v2018.01.0
v2017.12.0
v2017.11.0
v2017.10.0
v2017.09.0
v2017.08.0
v2017.07.1
v2017.07.0
v2017.06.2
v2017.06.1
v2017.06.0
v2017.05.4
v2017.05.3
v2017.05.2
v2017.05.1
v2017.05.0
v2017.04.0
v2017.03.0
v2017.02.0
v2017.01.0
v2016.11.0
v2016.10.0
v2016.09.0
v2016.08.0
v2016.07.0
v2016.06.0
v2016.05.0
|
---|
|
arch/arm/cpu/mmu.c |
---|
arch/arm/lib/barebox.lds.S |
---|