You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by xi...@apache.org on 2020/09/07 03:41:58 UTC
[incubator-nuttx] branch master updated: b-g474e-dpow1: Add support
for FLASH bootloader
This is an automated email from the ASF dual-hosted git repository.
xiaoxiang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-nuttx.git
The following commit(s) were added to refs/heads/master by this push:
new dc4c410 b-g474e-dpow1: Add support for FLASH bootloader
dc4c410 is described below
commit dc4c4102c3e2ffc2331b825a743971d5f84a058c
Author: Nathan Hartman <59...@users.noreply.github.com>
AuthorDate: Sun Sep 6 16:22:25 2020 -0400
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.
---
boards/arm/stm32/b-g474e-dpow1/README.txt | 23 ++++
boards/arm/stm32/b-g474e-dpow1/scripts/Make.defs | 10 +-
.../arm/stm32/b-g474e-dpow1/scripts/ld.script.dfu | 127 +++++++++++++++++++++
3 files changed, 158 insertions(+), 2 deletions(-)
diff --git a/boards/arm/stm32/b-g474e-dpow1/README.txt b/boards/arm/stm32/b-g474e-dpow1/README.txt
index 1ed7e60..99d465c 100644
--- a/boards/arm/stm32/b-g474e-dpow1/README.txt
+++ b/boards/arm/stm32/b-g474e-dpow1/README.txt
@@ -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
==============
diff --git a/boards/arm/stm32/b-g474e-dpow1/scripts/Make.defs b/boards/arm/stm32/b-g474e-dpow1/scripts/Make.defs
index 2575a0a..778ae49 100644
--- a/boards/arm/stm32/b-g474e-dpow1/scripts/Make.defs
+++ b/boards/arm/stm32/b-g474e-dpow1/scripts/Make.defs
@@ -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)
diff --git a/boards/arm/stm32/b-g474e-dpow1/scripts/ld.script.dfu b/boards/arm/stm32/b-g474e-dpow1/scripts/ld.script.dfu
new file mode 100644
index 0000000..2e526aa
--- /dev/null
+++ b/boards/arm/stm32/b-g474e-dpow1/scripts/ld.script.dfu
@@ -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) }
+}