On 29/01/2020 13:15, dufa...@hda.com wrote: > >> On Jan 29, 2020, at 03:13 , Christian Mauderer >> <christian.maude...@embedded-brains.de> wrote: >> >> Hello Peter, >> >> On 28/01/2020 22:37, dufa...@hda.com wrote: >>> >>>> On Jan 28, 2020, at 04:46 , Christian Mauderer >>>> <christian.maude...@embedded-brains.de> wrote: >>>> >>>> Before our customers migrated to libbsd (to get some of the features >>>> there) the driver in legacy worked. But that is a few years back. >>>> Currently I only know of applications using the libbsd driver. >>>> >>> >>> How are you linking the libbsd code? Where do you run the code from? >> >> May I start with a counter-question? Are you using an evaluation board >> or some custom one? Which chip variant are you using? All projects that >> I have been involved used one of the bigger chips (SAME70 or SAMV71). > > I put the BSP configuration in the original posting but I clipped it out, I > tend to like to clip. It's the SAMV71 "Xplained" Ultra. >
No problem. Just missed that in the first message. So it's one of the bigger chips too. >> >>> >>> The application I'm testing doesn't fit in the internal SRAM provided by >>> the default "linkcmds" in the libbsd case, partly because libbsd is bigger >>> and partly because when I build for "libbsd" it needs "libblock". >>> >> That depends on the project. One project where I can give you quite open >> information is GRiSP. That project is an evaluation platform for using >> Erlang on RTEMS. We did most of the initial the RTEMS stuff for it. You >> can find the basic RTEMS software here: >> >> https://github.com/grisp/grisp-software >> >> In this project we have a bootloader in the internal flash with some >> stuff in an SDRAM. See the linker command file for that: >> >> https://github.com/grisp/grisp-software/blob/master/grisp-bootloader/linkcmds.bootloader >> >> The bootloader doesn't have network support (I removed quite some bits >> with the "slim-down.h" file) but it uses libbsd for the SD card. It then >> starts a bigger RTEMS application from the SD card. That application >> uses libbsd for USB and WLAN. The application uses linkcmds.sdram from >> RTEMS. >> >>> It fits if I use "linkcmds.sdram", but then I can't run it because the >>> SDRAM must not be set up properly at reset, I guess I'd need to come up >>> with something using "openocd" that will set up the SDRAM before starting >>> the program. >>> >>> I then tried putting just REGION_START in internal flash but it fails when >>> it jump through a trampoline to "system_init_flash" which was still in the >>> SDRAM. >>> >>> Then I tried using "linkcmds.qspiflash" but the program didn't fit again >>> since more space was required in the internal SRAM. >>> >> >> We have another project where QSPI is used. I can't give you all details >> but some basic information are possible: >> >> This project starts a Bootloader from the internal flash. The bootloader >> would then start an application from QSPI XIP area. But it can also use >> libbsd for networking. The linkcmds for the bootloader look like follows: >> >> ```````` >> INCLUDE linkcmds.memory >> >> REGION_ALIAS ("REGION_START", INTFLASH); >> REGION_ALIAS ("REGION_VECTOR", INTSRAM); >> REGION_ALIAS ("REGION_TEXT", INTFLASH); >> REGION_ALIAS ("REGION_TEXT_LOAD", INTFLASH); >> REGION_ALIAS ("REGION_RODATA", INTFLASH); >> REGION_ALIAS ("REGION_RODATA_LOAD", INTFLASH); >> REGION_ALIAS ("REGION_DATA", SDRAM); >> REGION_ALIAS ("REGION_DATA_LOAD", INTFLASH); >> REGION_ALIAS ("REGION_FAST_TEXT", ITCM); >> REGION_ALIAS ("REGION_FAST_TEXT_LOAD", INTFLASH); >> REGION_ALIAS ("REGION_FAST_DATA", DTCM); >> REGION_ALIAS ("REGION_FAST_DATA_LOAD", INTFLASH); >> REGION_ALIAS ("REGION_BSS", SDRAM); >> REGION_ALIAS ("REGION_WORK", SDRAM); >> REGION_ALIAS ("REGION_STACK", SDRAM); >> REGION_ALIAS ("REGION_NOCACHE", NOCACHE); >> REGION_ALIAS ("REGION_NOCACHE_LOAD", INTFLASH); >> >> INCLUDE linkcmds.armv7m >> ```````` >> >> For the application that is put into QSPIFLASH it's the following: >> >> ```````` >> INCLUDE linkcmds.memory >> >> REGION_ALIAS ("REGION_START", QSPIFLASH); >> REGION_ALIAS ("REGION_VECTOR", INTSRAM); >> REGION_ALIAS ("REGION_TEXT", QSPIFLASH); >> REGION_ALIAS ("REGION_TEXT_LOAD", QSPIFLASH); >> REGION_ALIAS ("REGION_RODATA", QSPIFLASH); >> REGION_ALIAS ("REGION_RODATA_LOAD", QSPIFLASH); >> REGION_ALIAS ("REGION_DATA", SDRAM); >> REGION_ALIAS ("REGION_DATA_LOAD", QSPIFLASH); >> REGION_ALIAS ("REGION_FAST_TEXT", ITCM); >> REGION_ALIAS ("REGION_FAST_TEXT_LOAD", QSPIFLASH); >> REGION_ALIAS ("REGION_FAST_DATA", DTCM); >> REGION_ALIAS ("REGION_FAST_DATA_LOAD", QSPIFLASH); >> REGION_ALIAS ("REGION_BSS", SDRAM); >> REGION_ALIAS ("REGION_WORK", SDRAM); >> REGION_ALIAS ("REGION_STACK", SDRAM); >> REGION_ALIAS ("REGION_NOCACHE", NOCACHE); >> REGION_ALIAS ("REGION_NOCACHE_LOAD", SDRAM); >> >> INCLUDE linkcmds.armv7m >> ```````` >> >> I hope that helps. >> >> Best regards >> >> Christian >> >>> > This will help a lot. > > Is the bootloader for the second project the same as the one in "grisp" but > not slimmed down? No. It's a different one because there is a completely different boot concept. On GRiSP the boot is done from a SD card. For this customer the bootloader can update the program in the XIP area and start it from there. Let me know if I can help you with more information. Best regards Christian > > Thanks. I should have sent this to "-users", maybe I'll post a summary there > when done. > > Peter > ----------------- > Peter Dufault > HD Associates, Inc. Software and System Engineering > > This email is delivered through the public internet using protocols subject > to interception and tampering. > -- -------------------------------------------- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
