"atsamv" BSP legacy network driver status

[dufault at hda.com]

> On Jan 29, 2020, at 08:12 , Christian Mauderer <christian.mauderer at embedded-brains.de> wrote:
> 
> On 29/01/2020 13:15, dufault at hda.com wrote:
>> 
>>> On Jan 29, 2020, at 03:13 , Christian Mauderer <christian.mauderer at embedded-brains.de> wrote:
>>> 
>>> Hello Peter,
>>> 
>>> On 28/01/2020 22:37, dufault at hda.com wrote:
>>>> 
>>>>> On Jan 28, 2020, at 04:46 , Christian Mauderer <christian.mauderer at 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?

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.