Closed dromer closed 3 months ago
The only difference I see with the new linkers is there is a section BACKUP_SRAM
added.
Ou, I think that the change in the linker scripts is necessary for the bootup sequence to work properly (since it does use memory within the BACKUP_SRAM
in order to share data between the bootloader and the application).
I tried modifying the SDRAM linkers using the aforementioned BACKUP_SRAM
section (as it is in the regular SRAM linker), however I got the same result. Am I missing something here?
TLDR: Essentially I just replaced the table with:
FLASH (RX) : ORIGIN = 0x08000000, LENGTH = 128K
DTCMRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 128K
SRAM (RWX) : ORIGIN = 0x24000000, LENGTH = 512K - 32K
RAM_D2_DMA (RWX) : ORIGIN = 0x30000000, LENGTH = 32K
RAM_D2 (RWX) : ORIGIN = 0x30008000, LENGTH = 256K
RAM_D3 (RWX) : ORIGIN = 0x38000000, LENGTH = 64K
BACKUP_SRAM (RWX) : ORIGIN = 0x38800000, LENGTH = 4K
ITCMRAM (RWX) : ORIGIN = 0x00000000, LENGTH = 64K
SDRAM (RWX) : ORIGIN = 0xc0000000, LENGTH = 64M
QSPIFLASH (RX) : ORIGIN = 0x90040000, LENGTH = 7936K
And added this section:
.backup_sram (NOLOAD) :
{
. = ALIGN(4);
_sbackup_sram = .;
PROVIDE(__backup_sram_start = _sbackup_sram);
*(.backup_sram)
*(.backup_sram*)
. = ALIGN(4);
_ebackup_sram = .;
PROVIDE(__backup_sram_end = _ebackup_sram);
} > BACKUP_SRAM
@stephenhensley have you had a chance to check my modified LDS file, or perhaps investigate the SDRAM functionality with the new bootloader?
Ok! after some hints from @ndonald2 this was solved by reworking how the Heavy context gets initialized.
Doing it after hw.init()
completely solves the issue (using the reworked linker that I shared).
For instance https://github.com/electro-smith/pd2dsy/blob/master/util/sram_linker_sdram.lds results in Daisy disconnecting before it ever starts.
Is this a bug in the bootloader, or do we need to adjust these linker scripts?