SAMA5: Change mapping of vector tables to work around that fact that I don't understand how the AXI MATRIX remap works
This commit is contained in:
parent
8bfdf70766
commit
bfa1a9545b
@ -117,8 +117,37 @@ static const struct section_mapping_s section_mapping[] =
|
||||
{
|
||||
/* SAMA5 Internal Memories */
|
||||
|
||||
/* If CONFIG_ARCH_LOWVECTORS is defined, then the vectors located at the
|
||||
* beginning of the .text region must appear at address zero. There are
|
||||
* two ways to accomplish this:
|
||||
*
|
||||
* 1. By explicitly mapping the beginning of .text region with a page
|
||||
* table entry so that the virtual address zero maps to the beginning
|
||||
* of the .text region.
|
||||
* 2. A second way is to map the use the AXI MATRIX remap register to
|
||||
* map physical address zero to the beginning of the text region,
|
||||
* either internal SRAM or EBI CS 0. Then we can set an identity
|
||||
* mapping to map the boot region at 0x0000:0000 to virtual address
|
||||
* 0x0000:00000
|
||||
*
|
||||
* The first level bootloader is supposed to provide the AXI MATRIX
|
||||
* mapping for us at boot time base on the state of the BMS pin. However,
|
||||
* I have found that in the test environments that I use, I cannot always
|
||||
* be assured of that physical address mapping.
|
||||
*
|
||||
* So we do both here. If we are exectuing from FLASH, then we provide
|
||||
* the MMU to map the physical address of FLASH to address 0x0000:0000;
|
||||
* if we are executing from the internal SRAM, then we trust the bootload
|
||||
* to setup the AXI MATRIX mapping.
|
||||
*/
|
||||
|
||||
#if defined(CONFIG_ARCH_LOWVECTORS) && !defined(CONFIG_SAMA5_BOOT_ISRAM)
|
||||
{ CONFIG_FLASH_VSTART, 0x00000000, MMU_ROMFLAGS, 1},
|
||||
#else
|
||||
{ SAM_BOOTMEM_PSECTION, SAM_BOOTMEM_VSECTION,
|
||||
SAM_BOOTMEM_MMUFLAGS, SAM_BOOTMEM_NSECTIONS},
|
||||
#endif
|
||||
|
||||
{ SAM_ROM_PSECTION, SAM_ROM_VSECTION,
|
||||
SAM_ROM_MMUFLAGS, SAM_ROM_NSECTIONS},
|
||||
{ SAM_NFCSRAM_PSECTION, SAM_NFCSRAM_VSECTION,
|
||||
|
@ -284,6 +284,12 @@ void up_irqinitialize(void)
|
||||
putreg32(AIC_WPMR_WPKEY | AIC_WPMR_WPEN, SAM_AIC_WPMR);
|
||||
|
||||
#if defined(CONFIG_ARCH_LOWVECTORS) && defined(CONFIG_SAMA5_BOOT_ISRAM)
|
||||
/* Disable MATRIX write protection */
|
||||
|
||||
#if 0 /* Disabled on reset */
|
||||
putreg32(MATRIX_WPMR_WPKEY, SAM_MATRIX_WPMR);
|
||||
#endif
|
||||
|
||||
/* Set remap state 0 if we are running from internal SRAM. If we booted
|
||||
* into NOR FLASH, then the first level bootloader should have already
|
||||
* provided this mapping for us.
|
||||
@ -306,6 +312,12 @@ void up_irqinitialize(void)
|
||||
putreg32(MATRIX_MRCR_RCB0, SAM_MATRIX_MRCR); /* Enable remap */
|
||||
putreg32(AXIMX_REMAP_REMAP0, SAM_AXIMX_REMAP); /* Remap SRAM */
|
||||
|
||||
/* Restore MATRIX write protection */
|
||||
|
||||
#if 0 /* Disabled on reset */
|
||||
putreg32(MATRIX_WPMR_WPKEY | MATRIX_WPMR_WPEN, SAM_MATRIX_WPMR);
|
||||
#endif
|
||||
|
||||
/* It might be wise to flush the instruction cache here */
|
||||
#endif
|
||||
|
||||
|
@ -755,3 +755,7 @@ Configurations
|
||||
BMS jumper.
|
||||
|
||||
STATUS:
|
||||
2013-7-30: I have been unable to execute this configuration from NOR
|
||||
FLASH by closing the BMS jumper (J9). As far as I can tell, this
|
||||
jumper does nothing on my board??? I have been using the norboot
|
||||
configuration to start the program in NOR FLASH (see just above).
|
||||
|
@ -129,6 +129,12 @@ int nor_main(int argc, char *argv)
|
||||
|
||||
(void)irqdisable();
|
||||
|
||||
/* Disable MATRIX write protection */
|
||||
|
||||
#if 0 /* Disabled on reset */
|
||||
putreg32(MATRIX_WPMR_WPKEY, SAM_MATRIX_WPMR);
|
||||
#endif
|
||||
|
||||
/* Set remap state 1.
|
||||
*
|
||||
* Boot state: ROM is seen at address 0x00000000
|
||||
@ -136,11 +142,20 @@ int nor_main(int argc, char *argv)
|
||||
* interface) instead of ROM.
|
||||
* Remap State 1: HEBI is seen at address 0x00000000 (through AHB slave
|
||||
* interface) instead of ROM for external boot.
|
||||
*
|
||||
* REVISIT: This does not work. No matter what I do, the internal
|
||||
* SRAM is always visible at address zero. I am missing something.
|
||||
*/
|
||||
|
||||
putreg32(MATRIX_MRCR_RCB0, SAM_MATRIX_MRCR); /* Enable remap */
|
||||
putreg32(AXIMX_REMAP_REMAP1, SAM_AXIMX_REMAP); /* Remap HEBI */
|
||||
|
||||
/* Restore MATRIX write protection */
|
||||
|
||||
#if 0 /* Disabled on reset */
|
||||
putreg32(MATRIX_WPMR_WPKEY | MATRIX_WPMR_WPEN, SAM_MATRIX_WPMR);
|
||||
#endif
|
||||
|
||||
/* Disable the caches and the MMU. Disabling the MMU should be safe here
|
||||
* because there is a 1-to-1 identity mapping between the physical and
|
||||
* virtual addressing.
|
||||
@ -163,16 +178,21 @@ int nor_main(int argc, char *argv)
|
||||
#ifdef SAMA5_NOR_START
|
||||
/* Then jump into NOR flash */
|
||||
|
||||
// printf("Jumping to NOR flash on CS0\n");
|
||||
// fflush(stdout);
|
||||
// usleep(500*1000);
|
||||
#if 0 /* Trying to printf() in this state is fatal */
|
||||
printf("Jumping to NOR flash on CS0\n");
|
||||
fflush(stdout);
|
||||
usleep(500*1000);
|
||||
#endif
|
||||
|
||||
NOR_ENTRY();
|
||||
#else
|
||||
/* Or just wait patiently for the user to break in with GDB. */
|
||||
|
||||
// printf("Waiting for GDB halt\n");
|
||||
// fflush(stdout);
|
||||
#if 0 /* Trying to printf() in this state is fatal */
|
||||
printf("Waiting for GDB halt\n");
|
||||
fflush(stdout);
|
||||
#endif
|
||||
|
||||
for (;;);
|
||||
#endif
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user