On 29/01/2020 22:30, dufa...@hda.com wrote: > > >> On Jan 29, 2020, at 08:12 , Christian Mauderer >> <christian.maude...@embedded-brains.de> wrote: >> >> 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 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 >> > > > I thought I'd found an easy way to continue by just putting REGION_WORK in > SDRAM. That region isn't used until after the SDRAM is initialized. It > freed up lots of internal SRAM memory when not using "libbsd". > > Unfortunately it still overflows internal SRAM (INTSRAM) when using "libbsd". > I'm assuming that there isn't anything else assigned to INTSRAM that can > easily be moved to SDRAM where the SDRAM won't be used until after > initialization. Is that correct? >
The SDRAM initialization is done in bsp_start_hook_0. Most initialization is done in bsp_start_hook_1. You should be able to put the following into SDRAM without problems: - REGION_WORK - REGION_BSS - REGION_DATA - REGION_STACK If that's not enough, I would have to take a more detailed look. Best regards Christian > 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