b-g474e-dpow1: Add support for FLASH bootloader

boards/arm/stm32/b-g474e-dpow1/scripts/ld.script.dfu:

    * New file. Reserve up to 24KiB at the start of FLASH for a
      bootloader.

boards/arm/stm32/b-g474e-dpow1/scripts/Make.defs:

    * When building with CONFIG_STM32_DFU, use the new ld.script.dfu
      to leave room in FLASH for a bootloader.

boards/arm/stm32/b-g474e-dpow1/README.txt:

    * "FLASH Bootloader Support": New section.
This commit is contained in:
Nathan Hartman
2020-09-06 16:22:25 -04:00
committed by Xiang Xiao
parent d788b2e16c
commit dc4c4102c3
3 changed files with 158 additions and 2 deletions

View File

@@ -22,6 +22,7 @@ Contents
- LEDs
- RGB Power LED
- Serial Consoles
- FLASH Bootloader Support
- Configurations
@@ -114,6 +115,28 @@ Serial Consoles
differ.
FLASH Bootloader Support
========================
If implementing a FLASH bootloader, turn on Kconfig option CONFIG_STM32_DFU.
This option activates an alternate linker script, scripts/ld.script.dfu,
which causes NuttX to leave a gap at the start of FLASH, leaving that space
for the FLASH bootloader. See scripts/ld.script.dfu for details. It also
causes NuttX to relocate its vector table and possibly make other
adjustments.
One possible bootloader is STmicro's OpenBootloader "middleware" supplied
with STM32CubeG4 version 1.3.0. On the host (PC), it should be possible to
use STmicro's STM32CubeProgrammer or the stm32loader.py script from
https://github.com/jsnyder/stm32loader. That script can be invoked with
parameters such as:
stm32loader.py -p /dev/ttyACM0 -a 0x08006000 -e -w -v -g 0x08006000 nuttx.bin
where the given address (0x08006000 in this case) must match the starting
address in scripts/ld.script.dfu.
Configurations
==============

View File

@@ -22,12 +22,18 @@ include $(TOPDIR)/.config
include $(TOPDIR)/tools/Config.mk
include $(TOPDIR)/arch/arm/src/armv7-m/Toolchain.defs
ifeq ($(CONFIG_STM32_DFU),y)
LDSCRIPT = ld.script.dfu
else
LDSCRIPT = ld.script
endif
ifeq ($(CONFIG_CYGWIN_WINTOOL),y)
# Windows-native toolchains
ARCHSCRIPT = -T "${shell cygpath -w $(BOARD_DIR)$(DELIM)scripts$(DELIM)ld.script}"
ARCHSCRIPT = -T "${shell cygpath -w $(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)}"
else
# Linux/Cygwin-native toolchain
ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)ld.script
ARCHSCRIPT = -T$(BOARD_DIR)$(DELIM)scripts$(DELIM)$(LDSCRIPT)
endif
ifeq ($(CONFIG_DEBUG_SYMBOLS),y)

View File

@@ -0,0 +1,127 @@
/****************************************************************************
* boards/arm/stm32/b-g474e-dpow1/scripts/ld.script
*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership. The
* ASF licenses this file to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance with the
* License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*
****************************************************************************/
/* The STM32G474RE has 512 KiB of FLASH beginning at address 0x0800:0000.
*
* When booting from FLASH, FLASH memory is aliased to address 0x0000:0000
* where the code expects to begin execution by jumping to the entry point in
* the 0x0800:0000 address range. The FLASH bootloader is located there and
* allocated up to 24KiB (6 pages of 4k if single bank mode or 12 pages of 2k
* if dual bank mode), so our executable will begin at 0x0800:6000, leaving
* 488KiB.
*
* The STM32G474RE has a total of 128 KiB of SRAM in three separate areas:
*
* 1) 80 KiB SRAM1 mapped at 0x2000:0000 thru 0x2001:3fff.
* 2) 16 KiB SRAM2 mapped at 0x2001:4000 thru 0x2001:7fff.
*
* CCM SRAM (Routine Booster):
*
* 3) 32 KiB CCM SRAM mapped at 0x1000:0000 thru 0x1000:7fff
* but also aliased at at 0x2001:8000 thru 0x2001:ffff to be contiguous
* with the SRAM1 and SRAM2.
*
* Because SRAM1 and SRAM2 are contiguous, they are treated as one region
* by this logic.
*
* CCM SRAM is also contiguous to SRAM1 and SRAM2, however it is excluded
* from this linker script, to keep it reserved for special uses in code.
* REVISIT: Is this the correct way to handle CCM SRAM?
*/
MEMORY
{
flash (rx) : ORIGIN = 0x08006000, LENGTH = 488K
sram (rwx) : ORIGIN = 0x20000000, LENGTH = 96K
}
OUTPUT_ARCH(arm)
EXTERN(_vectors)
ENTRY(_stext)
SECTIONS
{
.text : {
_stext = ABSOLUTE(.);
*(.vectors)
*(.text .text.*)
*(.fixup)
*(.gnu.warning)
*(.rodata .rodata.*)
*(.gnu.linkonce.t.*)
*(.glue_7)
*(.glue_7t)
*(.got)
*(.gcc_except_table)
*(.gnu.linkonce.r.*)
_etext = ABSOLUTE(.);
} > flash
.init_section : ALIGN(4) {
_sinit = ABSOLUTE(.);
*(.init_array .init_array.*)
_einit = ABSOLUTE(.);
} > flash
.ARM.extab : ALIGN(4) {
*(.ARM.extab*)
} > flash
.ARM.exidx : ALIGN(4) {
__exidx_start = ABSOLUTE(.);
*(.ARM.exidx*)
__exidx_end = ABSOLUTE(.);
} > flash
_eronly = ABSOLUTE(.);
.data : ALIGN(4) {
_sdata = ABSOLUTE(.);
*(.data .data.*)
*(.gnu.linkonce.d.*)
CONSTRUCTORS
. = ALIGN(4);
_edata = ABSOLUTE(.);
} > sram AT > flash
.bss : ALIGN(4) {
_sbss = ABSOLUTE(.);
*(.bss .bss.*)
*(.gnu.linkonce.b.*)
*(COMMON)
. = ALIGN(4);
_ebss = ABSOLUTE(.);
} > sram
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_info 0 : { *(.debug_info) }
.debug_line 0 : { *(.debug_line) }
.debug_pubnames 0 : { *(.debug_pubnames) }
.debug_aranges 0 : { *(.debug_aranges) }
}