From bb7fbad8bd854d364b72c3f6466fcece7ddc991c Mon Sep 17 00:00:00 2001 From: Gregory Nutt Date: Sun, 30 Mar 2014 10:25:01 -0600 Subject: [PATCH] cosmetic updates to comments --- arch/arm/src/sama5/sam_boot.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/arch/arm/src/sama5/sam_boot.c b/arch/arm/src/sama5/sam_boot.c index fa5b71fe60..a5c0de6c6b 100644 --- a/arch/arm/src/sama5/sam_boot.c +++ b/arch/arm/src/sama5/sam_boot.c @@ -135,15 +135,19 @@ static const struct section_mapping_s section_mapping[] = * 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. + * When executing from NOR FLASH, 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 executing 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 we are executing out of ISRAM, then the SAMA5 primary bootloader + * probably copied us into ISRAM. If we are executing from external + * SDRAM, then a secondary bootloader must have loaded us into SDRAM. In + * either case we trust the bootloader to setup the AXI MATRIX mapping on + * our behalf. */ #if defined(CONFIG_ARCH_LOWVECTORS) && !defined(CONFIG_SAMA5_BOOT_ISRAM) && \