Re: "atsamv" BSP legacy network driver status
On 31/01/2020 13:39, dufa...@hda.com wrote:
>
>
>> On Jan 31, 2020, at 01:31 , Christian Mauderer
>> wrote:
>>
>> On 30/01/2020 22:12, dufa...@hda.com wrote:
>>>
>>>
On Jan 30, 2020, at 01:24 , Christian Mauderer
wrote:
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
>>>
>>> Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't
>>> work? Details:
>>>
>>> Putting those sections into SDRAM worked perfectly, perfectly enough to
>>> duplicate the problem I had with the legacy stack using the "libbsd" stack.
>>> The symptoms are the same:
>>>
>>> - The network stack is initialized.
>>> - The network stack is receiving incoming packets.
>>> - No transmit packets are sent out. The software is trying to send out
>>> packets but they never go out.
>>>
>>> I'm looking at two of many possibilities as most likely.
>>> 1. Do I have the media setup mis-configured so it can't transmit?
>>> -- Unlikely if that's the case since it's receiving.
>>> -- In the case of using the "libbsd" stack I'm using "ifconfig if-atsam0
>>> (ip-address) netmask (netmask) media 100TX up", and it starts receiving
>>> packets but not sending.
>>
>> Just an idea: With Ethernet I have already seen hardware bugs that lead
>> to the effect that a device wouldn't work on one switch but worked
>> completely fine on another. Such stuff can also have an influence on the
>> direction. Did you test stuff like connecting to another switch, maybe
>> using another speed (10MBit), connecting to a PC directly, ...
>>
>>> 2. The second possibility. I'm looking at this now, and I'm sending the
>>> email so that you can tell me to stop wasting my time.
>>>
>>> Is it possible this is related to not initializing transmit FIFOS? My
>>> google searches have turned up really similar situations associated with
>>> not initializing registers for queues that I don't think exist.
>>>
>>> I haven't sorted this out yet but look at:
>>> https://www.avrfreaks.net/comment/2648206#comment-2648206
>>> "I found the problem, at least in the ASF4 code base for Revision B chips
>>> The Revision B chips have 6 priority transmit fifos (there is an errata
>>> regarding this for the Rev A chips)
>>> Each of these fifos have to be initialized before sending can occur, Atmel
>>> tried to do this at the end ..."
>>> I went to ... because it doesn't apply after this point.
>>
>> If that is a problem with newer chips, that is a quite possible reason.
>> From a quick look into the driver it seems that we only initialize three
>> queues. I also had a quick look at one of the customer boards we have
>> and it seems to be a revision A chip.
>>
>> Revision A chips seem to have only three queues even if the data sheet
>> describes 6. So that could match too.
>>
>> It seems that our driver sets up the queues with the same buffer. Have
>> you tried just adding the remaining 3 buffers below the lines
>>
>> GMAC_SetRxQueue(pHw, (uint32_t)buffer_desc, 1);
>> GMAC_SetRxQueue(pHw, (uint32_t)buffer_desc, 2);
>>
>> and
>>
>> GMAC_SetTxQueue(pHw, (uint32_t)buffer_desc, 1);
>> GMAC_SetTxQueue(pHw, (uint32_t)buffer_desc, 2);
>>
>> There is a CHIPID_CIDR.VERSION register that gives the chip revision. So
>> if that works, it maybe would be good to do that only for chips with
>> this field set to revision B and newer (value >= 0x1).
>>
>>>
>>> The newest Microchip / Atmel support package, the one that the "atsamv" BSP
>>> is *not* based on (and that is totally, totally reorganized and will be
>>> difficult to rebase on) includes "dummy buffers for unconfigured queues".
>>
>> Yes, I know. It's really annoying that the new library isn't compatible.
>> I think that discussion popped up two or three times on the list. It
>> would be great if someone would have the time for an upgrade.
>>
>>>
>>>for (i = 0; i < GMAC_QUEUE_COUNT; i++) {
>>>gmacd_setup_queue(gmacd, i,
>>>DUMMY_BUFFERS, dummy_buffer, dummy_rx_desc,
>>>DUMMY_BUFFERS, dummy_buffer, dummy_tx_desc,
>>>NULL);
>>>}
>>>
>>> So, as I said:
>>>
>>> Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't
>>> work?
>>
>> I would say that it is possible.
>>
>> 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
>>
Re: "atsamv" BSP legacy network driver status
> On Jan 31, 2020, at 01:31 , Christian Mauderer
> wrote:
>
> On 30/01/2020 22:12, dufa...@hda.com wrote:
>>
>>
>>> On Jan 30, 2020, at 01:24 , Christian Mauderer
>>> wrote:
>>>
>>> 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
>>
>> Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't work?
>> Details:
>>
>> Putting those sections into SDRAM worked perfectly, perfectly enough to
>> duplicate the problem I had with the legacy stack using the "libbsd" stack.
>> The symptoms are the same:
>>
>> - The network stack is initialized.
>> - The network stack is receiving incoming packets.
>> - No transmit packets are sent out. The software is trying to send out
>> packets but they never go out.
>>
>> I'm looking at two of many possibilities as most likely.
>> 1. Do I have the media setup mis-configured so it can't transmit?
>> -- Unlikely if that's the case since it's receiving.
>> -- In the case of using the "libbsd" stack I'm using "ifconfig if-atsam0
>> (ip-address) netmask (netmask) media 100TX up", and it starts receiving
>> packets but not sending.
>
> Just an idea: With Ethernet I have already seen hardware bugs that lead
> to the effect that a device wouldn't work on one switch but worked
> completely fine on another. Such stuff can also have an influence on the
> direction. Did you test stuff like connecting to another switch, maybe
> using another speed (10MBit), connecting to a PC directly, ...
>
>> 2. The second possibility. I'm looking at this now, and I'm sending the
>> email so that you can tell me to stop wasting my time.
>>
>> Is it possible this is related to not initializing transmit FIFOS? My
>> google searches have turned up really similar situations associated with not
>> initializing registers for queues that I don't think exist.
>>
>> I haven't sorted this out yet but look at:
>> https://www.avrfreaks.net/comment/2648206#comment-2648206
>> "I found the problem, at least in the ASF4 code base for Revision B chips
>> The Revision B chips have 6 priority transmit fifos (there is an errata
>> regarding this for the Rev A chips)
>> Each of these fifos have to be initialized before sending can occur, Atmel
>> tried to do this at the end ..."
>> I went to ... because it doesn't apply after this point.
>
> If that is a problem with newer chips, that is a quite possible reason.
> From a quick look into the driver it seems that we only initialize three
> queues. I also had a quick look at one of the customer boards we have
> and it seems to be a revision A chip.
>
> Revision A chips seem to have only three queues even if the data sheet
> describes 6. So that could match too.
>
> It seems that our driver sets up the queues with the same buffer. Have
> you tried just adding the remaining 3 buffers below the lines
>
> GMAC_SetRxQueue(pHw, (uint32_t)buffer_desc, 1);
> GMAC_SetRxQueue(pHw, (uint32_t)buffer_desc, 2);
>
> and
>
> GMAC_SetTxQueue(pHw, (uint32_t)buffer_desc, 1);
> GMAC_SetTxQueue(pHw, (uint32_t)buffer_desc, 2);
>
> There is a CHIPID_CIDR.VERSION register that gives the chip revision. So
> if that works, it maybe would be good to do that only for chips with
> this field set to revision B and newer (value >= 0x1).
>
>>
>> The newest Microchip / Atmel support package, the one that the "atsamv" BSP
>> is *not* based on (and that is totally, totally reorganized and will be
>> difficult to rebase on) includes "dummy buffers for unconfigured queues".
>
> Yes, I know. It's really annoying that the new library isn't compatible.
> I think that discussion popped up two or three times on the list. It
> would be great if someone would have the time for an upgrade.
>
>>
>>for (i = 0; i < GMAC_QUEUE_COUNT; i++) {
>>gmacd_setup_queue(gmacd, i,
>>DUMMY_BUFFERS, dummy_buffer, dummy_rx_desc,
>>DUMMY_BUFFERS, dummy_buffer, dummy_tx_desc,
>>NULL);
>>}
>>
>> So, as I said:
>>
>> Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't work?
>
> I would say that it is possible.
>
> 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
Re: "atsamv" BSP legacy network driver status
On 30/01/2020 22:12, dufa...@hda.com wrote:
>
>
>> On Jan 30, 2020, at 01:24 , Christian Mauderer
>> wrote:
>>
>> 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
>
> Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't work?
> Details:
>
> Putting those sections into SDRAM worked perfectly, perfectly enough to
> duplicate the problem I had with the legacy stack using the "libbsd" stack.
> The symptoms are the same:
>
> - The network stack is initialized.
> - The network stack is receiving incoming packets.
> - No transmit packets are sent out. The software is trying to send out
> packets but they never go out.
>
> I'm looking at two of many possibilities as most likely.
> 1. Do I have the media setup mis-configured so it can't transmit?
> -- Unlikely if that's the case since it's receiving.
> -- In the case of using the "libbsd" stack I'm using "ifconfig if-atsam0
> (ip-address) netmask (netmask) media 100TX up", and it starts receiving
> packets but not sending.
Just an idea: With Ethernet I have already seen hardware bugs that lead
to the effect that a device wouldn't work on one switch but worked
completely fine on another. Such stuff can also have an influence on the
direction. Did you test stuff like connecting to another switch, maybe
using another speed (10MBit), connecting to a PC directly, ...
> 2. The second possibility. I'm looking at this now, and I'm sending the
> email so that you can tell me to stop wasting my time.
>
> Is it possible this is related to not initializing transmit FIFOS? My google
> searches have turned up really similar situations associated with not
> initializing registers for queues that I don't think exist.
>
> I haven't sorted this out yet but look at:
> https://www.avrfreaks.net/comment/2648206#comment-2648206
> "I found the problem, at least in the ASF4 code base for Revision B chips
> The Revision B chips have 6 priority transmit fifos (there is an errata
> regarding this for the Rev A chips)
> Each of these fifos have to be initialized before sending can occur, Atmel
> tried to do this at the end ..."
> I went to ... because it doesn't apply after this point.
If that is a problem with newer chips, that is a quite possible reason.
From a quick look into the driver it seems that we only initialize three
queues. I also had a quick look at one of the customer boards we have
and it seems to be a revision A chip.
Revision A chips seem to have only three queues even if the data sheet
describes 6. So that could match too.
It seems that our driver sets up the queues with the same buffer. Have
you tried just adding the remaining 3 buffers below the lines
GMAC_SetRxQueue(pHw, (uint32_t)buffer_desc, 1);
GMAC_SetRxQueue(pHw, (uint32_t)buffer_desc, 2);
and
GMAC_SetTxQueue(pHw, (uint32_t)buffer_desc, 1);
GMAC_SetTxQueue(pHw, (uint32_t)buffer_desc, 2);
There is a CHIPID_CIDR.VERSION register that gives the chip revision. So
if that works, it maybe would be good to do that only for chips with
this field set to revision B and newer (value >= 0x1).
>
> The newest Microchip / Atmel support package, the one that the "atsamv" BSP
> is *not* based on (and that is totally, totally reorganized and will be
> difficult to rebase on) includes "dummy buffers for unconfigured queues".
Yes, I know. It's really annoying that the new library isn't compatible.
I think that discussion popped up two or three times on the list. It
would be great if someone would have the time for an upgrade.
>
> for (i = 0; i < GMAC_QUEUE_COUNT; i++) {
> gmacd_setup_queue(gmacd, i,
> DUMMY_BUFFERS, dummy_buffer, dummy_rx_desc,
> DUMMY_BUFFERS, dummy_buffer, dummy_tx_desc,
> NULL);
> }
>
> So, as I said:
>
> Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't work?
I would say that it is possible.
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
Re: "atsamv" BSP legacy network driver status
> On Jan 30, 2020, at 01:24 , Christian Mauderer
> wrote:
>
> 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
Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't work?
Details:
Putting those sections into SDRAM worked perfectly, perfectly enough to
duplicate the problem I had with the legacy stack using the "libbsd" stack.
The symptoms are the same:
- The network stack is initialized.
- The network stack is receiving incoming packets.
- No transmit packets are sent out. The software is trying to send out packets
but they never go out.
I'm looking at two of many possibilities as most likely.
1. Do I have the media setup mis-configured so it can't transmit?
-- Unlikely if that's the case since it's receiving.
-- In the case of using the "libbsd" stack I'm using "ifconfig if-atsam0
(ip-address) netmask (netmask) media 100TX up", and it starts receiving packets
but not sending.
2. The second possibility. I'm looking at this now, and I'm sending the email
so that you can tell me to stop wasting my time.
Is it possible this is related to not initializing transmit FIFOS? My google
searches have turned up really similar situations associated with not
initializing registers for queues that I don't think exist.
I haven't sorted this out yet but look at:
https://www.avrfreaks.net/comment/2648206#comment-2648206
"I found the problem, at least in the ASF4 code base for Revision B chips
The Revision B chips have 6 priority transmit fifos (there is an errata
regarding this for the Rev A chips)
Each of these fifos have to be initialized before sending can occur, Atmel
tried to do this at the end ..."
I went to ... because it doesn't apply after this point.
The newest Microchip / Atmel support package, the one that the "atsamv" BSP is
*not* based on (and that is totally, totally reorganized and will be difficult
to rebase on) includes "dummy buffers for unconfigured queues".
for (i = 0; i < GMAC_QUEUE_COUNT; i++) {
gmacd_setup_queue(gmacd, i,
DUMMY_BUFFERS, dummy_buffer, dummy_rx_desc,
DUMMY_BUFFERS, dummy_buffer, dummy_tx_desc,
NULL);
}
So, as I said:
Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't work?
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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: "atsamv" BSP legacy network driver status
On 29/01/2020 22:30, dufa...@hda.com wrote: > > >> On Jan 29, 2020, at 08:12 , Christian Mauderer >> wrote: >> >> On 29/01/2020 13:15, dufa...@hda.com wrote: >>> On Jan 29, 2020, at 03:13 , Christian Mauderer wrote: Hello Peter, On 28/01/2020 22:37, dufa...@hda.com wrote: > >> On Jan 28, 2020, at 04:46 , Christian Mauderer >> 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
Re: "atsamv" BSP legacy network driver status
> On Jan 29, 2020, at 08:12 , Christian Mauderer > wrote: > > On 29/01/2020 13:15, dufa...@hda.com wrote: >> >>> On Jan 29, 2020, at 03:13 , Christian Mauderer >>> wrote: >>> >>> Hello Peter, >>> >>> On 28/01/2020 22:37, dufa...@hda.com wrote: > On Jan 28, 2020, at 04:46 , Christian Mauderer > 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: "atsamv" BSP legacy network driver status
On 29/01/2020 13:15, dufa...@hda.com wrote:
>
>> On Jan 29, 2020, at 03:13 , Christian Mauderer
>> wrote:
>>
>> Hello Peter,
>>
>> On 28/01/2020 22:37, dufa...@hda.com wrote:
>>>
On Jan 28, 2020, at 04:46 , Christian Mauderer
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
Re: "atsamv" BSP legacy network driver status
> On Jan 29, 2020, at 03:13 , Christian Mauderer
> wrote:
>
> Hello Peter,
>
> On 28/01/2020 22:37, dufa...@hda.com wrote:
>>
>>> On Jan 28, 2020, at 04:46 , Christian Mauderer
>>> 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.
>
>>
>> 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?
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
Re: "atsamv" BSP legacy network driver status
Hello Peter,
On 28/01/2020 22:37, dufa...@hda.com wrote:
>
>> On Jan 28, 2020, at 04:46 , Christian Mauderer
>> 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).
>
> 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
> I need to:
> - reduce the size by figuring out how to get rid of "libblock" (it isn't
> needed in the non libbsd case);
> - figure out how to set things up so that "openocd" works using the SDRAM;
> - or relocate everything needed prior to initializing SDRAM to be in the
> internal flash.
>
> This is still an evaluation so I only want to see it run.
>
> 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
Re: "atsamv" BSP legacy network driver status
> On Jan 28, 2020, at 04:46 , Christian Mauderer > 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? 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". 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. I need to: - reduce the size by figuring out how to get rid of "libblock" (it isn't needed in the non libbsd case); - figure out how to set things up so that "openocd" works using the SDRAM; - or relocate everything needed prior to initializing SDRAM to be in the internal flash. This is still an evaluation so I only want to see it run. 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: "atsamv" BSP legacy network driver status
Hello Peter,
On 27/01/2020 22:10, Peter Dufault wrote:
> The "rtems-libbsd" "if_atsam.c" driver is derived from the legacy one.
Correct.
> What's the status of the two drivers? I ask because I'm trying to do some
> small memory testing with the legacy stack on the . It is building but not
> working, I don't think network packets are going out even though the build is
> definitely receiving broadcast packets because I see the number of incoming
> receive interrupts increasing.
The last one I tried is the one in rtems-libbsd in commit
c1e05b9ea378b2971e3d7704779112b4bc4296da on the 5-freebsd-12 branch.
That one worked and is used by some of our customers. Since then nothing
changed at that driver (neither on master nor on the branch). So I would
expect that it still works.
It is a long time since I last tried the one inside the legacy stack.
>
> My first attempts crashed because the attach function unconditionally
> de-referenced "config->hardware_address", most legacy drivers conditionalize
> the de-reference. I modified the driver to do something similar to what the
> "libbsd" driver does.>
> After that everything appears to work except networking isn't working. I put
> the system on its own little section of a managed switch and I don't see any
> packet activity. The app is running a shell with "netstat" and I can see the
> count of receive interrupts going up.
>
> Before I go much further I have a few questions.
>
> - What's the usage of the "atsamv" driver? I know there are issues
> associated with the external SRAM, clock speeds, and maybe clock references.
> But is the legacy driver used, only the "libbsd" driver used, or neither?
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.
Best regards
Christian
>
> Thanks -
>
> Peter
>
>
> The diffs I made to the driver are:
>
> diff --git a/bsps/arm/atsam/net/if_atsam.c b/bsps/arm/atsam/net/if_atsam.c
> index 9665aa1..5c84cdc 100644
> --- a/bsps/arm/atsam/net/if_atsam.c
> +++ b/bsps/arm/atsam/net/if_atsam.c
> @@ -1181,6 +1181,10 @@ static int if_atsam_driver_attach(struct
> rtems_bsdnet_ifconfig *config)
> const if_atsam_config *conf = config->drv_ctrl;
> int unitNumber;
> char *unitName;
> +/* This is sort of what the libbsd library does for the lack of a MAC
> address.
> + * except the final byte is 0x11 + unit.
> + */
> +static const uint8_t mac_addr[] = { 0x0e, 0xb0, 0xba, 0x5e, 0xba, 0x11
> /* + unit */ };
>
> if (conf != NULL) {
> sc->Gmac_inst.retries = conf->mdio_retries;
> @@ -1191,7 +1195,11 @@ static int if_atsam_driver_attach(struct
> rtems_bsdnet_ifconfig *config)
> }
>
> /* The MAC address used */
> - memcpy(sc->GMacAddress, config->hardware_address, ETHER_ADDR_LEN);
> +if (config->hardware_address) {
> +memcpy(sc->GMacAddress, config->hardware_address, ETHER_ADDR_LEN);
> +} else {
> +memcpy(sc->GMacAddress, mac_addr, ETHER_ADDR_LEN);
> +}
> memcpy(sc->arpcom.ac_enaddr, sc->GMacAddress, ETHER_ADDR_LEN);
>
> /*
>
>
>
> *** Configuration command is:
>
> ../rtems/configure \
> --target=arm-rtems5 \
> --enable-rtemsbsp=atsamv \
> --prefix=/opt/customer/rtems-5/ \
> --enable-networking \
> --enable-posix \
> --disable-smp \
> --disable-multiprocessing \
> --enable-tests \
> --enable-cxx \
> --enable-maintainer-mode
>
>
> 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.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
--
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
