arc: hsdk: Set SRAM_BASE_ADDRESS in defconfig #20782
Conversation
|
I like the suggestion to make hsdk board support more robust, independent of the boot remapping settings of the board. But, wouldn't this be something to fix through dts file definitions instead of overriding CONFIG_SRAM_BASE_ADDRESS in a header file? And, maybe make the dts memory configurations in the dts files reflect all the memories/options (e.g. I didn't see DCCM memory defined). |
only 2 cores have ICCM and DCCM in HSDK board, so we didn't add ICCM or DCCM memory defined yet. |
|
Line 64 in b329312 I think the root cause is in this file |
On power-on boot-ROM is mapped to address 0 in HSDK board. Normally later when U-Boot gets started by boot-ROM we change mappings so that real DDR is mapped to entire address space including 0: https://elixir.bootlin.com/u-boot/latest/source/board/synopsys/hsdk/hsdk.c#L474 But if U-Boot is not started (which is controlled by the BIM dip-switch on the board) boot-ROM remains mapped to 0, and essentially any attempt to write to that location fails, thus we cannot upload contents of our target Elf there even with JTAG. The next logical option is to use beginning of the non-translated memory region 0x8000_0000 which we typically use for loading U-Boot & Linux kernel on ARC boards. But in case of HSDK we have DCCM (Data Closely-Coupled MEmory - fast on-chip SRAM) mapped there and since we cannot execute code from DCCM we need to skip that region as well which gives us the next option being 0x9000_0000 . That's because DCCM owns entire 256 MiB "aperture" even though it may have much smaller size up-to 8 MiB. We are mapping only 5 apertures because the last two (0xe000_0000-0xffff_ffff) are used for peripherals and AXI. Signed-off-by: Evgeniy Didin <[email protected]> Signed-off-by: Alexey Brodkin <[email protected]>
EvgeniiDidin
force-pushed
the
topic-hsdk-sram-address
branch
from
f408f56 to
2b89037
Compare
|
Moved memory mapping in dts/arc/arc_hsdk.dtsi file. |
ruuddw
left a comment
ruuddw
left a comment
There was a problem hiding this comment.
ok for now
(a future enhancement would be to add CCM memories and (user) selection of what type of memory to use).
7 participants
On power-on boot-ROM is mapped to address 0 in HSDK board.
Normally later when U-Boot gets started by boot-ROM we change mappings
so that real DDR is mapped to entire address space including 0:
https://elixir.bootlin.com/u-boot/latest/source/board/synopsys/hsdk/hsdk.c#L474
But if U-Boot is not started (which is controlled by the BIM dip-switch
on the board) boot-ROM remains mapped to 0, and essentially any attempt
to write to that location fails, thus we cannot upload contents of our
target Elf there even with JTAG.
The next logical option is to use beginning of the non-translated
memory region 0x8000_0000 which we typically use for loading
U-Boot & Linux kernel on ARC boards. But in case of HSDK
we have DCCM (Data Closely-Coupled MEmory - fast on-chip SRAM)
mapped there and since we cannot execute code from DCCM
we need to skip that region as well which gives us the next option
being 0x9000_0000 . That's because DCCM owns entire 256 MiB "aperture"
even though it may have much smaller size up-to 8 MiB.
Signed-off-by: Evgeniy Didin [email protected]
Signed-off-by: Alexey Brodkin [email protected]