"atsamv" BSP legacy network driver status

[Christian Mauderer]

On 29/01/2020 22:30, dufault at hda.com wrote:
> 
> 
>> 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?
> 

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.mauderer at 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.