"atsamv" BSP legacy network driver status

Wed Jan 29 13:12:55 UTC 2020

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