* Ethernet over SPI driver for ENC424J600
@ 2010-02-03 9:37 Ilija Stanislevik
2010-02-03 13:13 ` Simon Kallweit
2010-02-04 9:17 ` John Dallaway
0 siblings, 2 replies; 24+ messages in thread
From: Ilija Stanislevik @ 2010-02-03 9:37 UTC (permalink / raw)
To: eCos developers
Hi,
I tested the driver at Ethernet level: sending and receiving Ethernet
packets, setting and getting ESA, etc. The tests have been done on
STM3210E evaluation board (ST cortex M3 processor). Now I am trying to
perform tests with lwip stack.
First I did some initial testing with ecos3.0. Using configtool I chose
ecos3.0 repository, ST STM3210E EVAL board template and lwip_eth package
instead of default. I added my driver source and CDL files to my local
ecos3.0 repository. Everything builds fine.
Then I decided to try the lwip from the CVS. Using configtool I chose
current ecos repository (taken from CVS on February 2. 2010), ST
STM3210E EVAL board template and lwip_eth package. I added my driver
source and CDL files to my local repository. Building library does not
yield:
.
.
home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:72:27:
error: netif/ppp/ppp.h: No such file or directory
/home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:73:28:
error: netif/ppp/chat.h: No such file or directory
/home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:190:8:
warning: multi-line comment
make[1]: Leaving directory
`/home/iko/Agenda/Energ/Ramnenje/Dizajn/STM32/EVALB/ecos/test_current_ecos_build/net/lwip_tcpip/current'
make[1]: *** [src/ecos/simple.o.d] Error 1
make: Leaving directory
`/home/iko/Agenda/Energ/Ramnenje/Dizajn/STM32/EVALB/ecos/test_current_ecos_build'
make: *** [build] Error 2
Any suggestions how to get on track?
Ilija Stanislevik
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2010-02-03 9:37 Ethernet over SPI driver for ENC424J600 Ilija Stanislevik
@ 2010-02-03 13:13 ` Simon Kallweit
2010-02-04 9:17 ` John Dallaway
1 sibling, 0 replies; 24+ messages in thread
From: Simon Kallweit @ 2010-02-03 13:13 UTC (permalink / raw)
To: Ilija Stanislevik; +Cc: eCos developers
Ilija Stanislevik wrote:
> Hi,
>
> I tested the driver at Ethernet level: sending and receiving Ethernet
> packets, setting and getting ESA, etc. The tests have been done on
> STM3210E evaluation board (ST cortex M3 processor). Now I am trying to
> perform tests with lwip stack.
>
> First I did some initial testing with ecos3.0. Using configtool I chose
> ecos3.0 repository, ST STM3210E EVAL board template and lwip_eth package
> instead of default. I added my driver source and CDL files to my local
> ecos3.0 repository. Everything builds fine.
>
> Then I decided to try the lwip from the CVS. Using configtool I chose
> current ecos repository (taken from CVS on February 2. 2010), ST
> STM3210E EVAL board template and lwip_eth package. I added my driver
> source and CDL files to my local repository. Building library does not
> yield:
>
> .
> .
>
> home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:72:27:
> error: netif/ppp/ppp.h: No such file or directory
>
> /home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:73:28:
> error: netif/ppp/chat.h: No such file or directory
>
> /home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:190:8:
> warning: multi-line comment
> make[1]: Leaving directory
>
> `/home/iko/Agenda/Energ/Ramnenje/Dizajn/STM32/EVALB/ecos/test_current_ecos_build/net/lwip_tcpip/current'
> make[1]: *** [src/ecos/simple.o.d] Error 1
> make: Leaving directory
>
> `/home/iko/Agenda/Energ/Ramnenje/Dizajn/STM32/EVALB/ecos/test_current_ecos_build'
> make: *** [build] Error 2
>
> Any suggestions how to get on track?
Hmm, I just did the following, using the latest CVS repository:
ecosconfig new stm3210e_eval lwip_eth
ecosconfig tree
make
make -C net/lwip_tcpip/current/ tests
Everything builds, as far as I can see. Try to recreate your tree, or
start with a clean configuration again.
Simon
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2010-02-03 9:37 Ethernet over SPI driver for ENC424J600 Ilija Stanislevik
2010-02-03 13:13 ` Simon Kallweit
@ 2010-02-04 9:17 ` John Dallaway
2010-02-05 7:59 ` Ilija Stanislevik
2010-02-05 8:16 ` Ilija Kocho
1 sibling, 2 replies; 24+ messages in thread
From: John Dallaway @ 2010-02-04 9:17 UTC (permalink / raw)
To: Ilija Stanislevik; +Cc: eCos developers
Hi Ilija
Ilija Stanislevik wrote:
> home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:72:27:
> error: netif/ppp/ppp.h: No such file or directory
[ snip ]
> Any suggestions how to get on track?
net/lwip_tcpip/current/include/netif/ppp/ is a new directory. Does it
exist in your local CVS checkout? For avoidance of doubt, you need the
"-d" switch when updating:
cd packages
cvs -q update -d -P net/lwip_tcpip io/eth
John Dallaway
eCos maintainer
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2010-02-04 9:17 ` John Dallaway
@ 2010-02-05 7:59 ` Ilija Stanislevik
2010-02-05 8:16 ` Ilija Kocho
1 sibling, 0 replies; 24+ messages in thread
From: Ilija Stanislevik @ 2010-02-05 7:59 UTC (permalink / raw)
To: John Dallaway; +Cc: eCos developers
Hi John,
> net/lwip_tcpip/current/include/netif/ppp/ is a new directory. Does it
> exist in your local CVS checkout? For avoidance of doubt, you need the
> "-d" switch when updating:
>
> cd packages
> cvs -q update -d -P net/lwip_tcpip io/et
Your suggestion solved the problem. Thank you.
Ilija Stanislevik
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2010-02-04 9:17 ` John Dallaway
2010-02-05 7:59 ` Ilija Stanislevik
@ 2010-02-05 8:16 ` Ilija Kocho
2010-02-05 10:26 ` Ross Younger
1 sibling, 1 reply; 24+ messages in thread
From: Ilija Kocho @ 2010-02-05 8:16 UTC (permalink / raw)
To: eCos developers
John Dallaway wrote:
> net/lwip_tcpip/current/include/netif/ppp/ is a new directory. Does it
> exist in your local CVS checkout? For avoidance of doubt, you need the
> "-d" switch when updating:
>
> cd packages
> cvs -q update -d -P net/lwip_tcpip io/eth
>
Is this some "unwanted feature" of CVS? If yes one more reason to switch
to new VCS.
// Ilija
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2010-02-05 8:16 ` Ilija Kocho
@ 2010-02-05 10:26 ` Ross Younger
0 siblings, 0 replies; 24+ messages in thread
From: Ross Younger @ 2010-02-05 10:26 UTC (permalink / raw)
To: eCos developers
> John Dallaway wrote:
>> net/lwip_tcpip/current/include/netif/ppp/ is a new directory.
>> [...] you need the "-d" switch when updating
Ilija Kocho wrote:
> Is this some "unwanted feature" of CVS? If yes one more reason to switch
> to new VCS.
CVS has always been that way: you never get new directories in a cvs update
unless you use the -d option. Those of us who have been working heavily with
it for upwards of a decade (!) find it works its way into our finger macros,
and/or create a .cvsrc with "update -d" (and maybe -P as well for neatness).
Ross
--
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071. www.ecoscentric.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Ethernet over SPI driver for ENC424J600
@ 2010-02-16 8:20 Ilija Stanislevik
2010-02-16 19:03 ` John Dallaway
0 siblings, 1 reply; 24+ messages in thread
From: Ilija Stanislevik @ 2010-02-16 8:20 UTC (permalink / raw)
To: eCos developers
Hi,
The work on the driver is pretty much done. I intend to spend a day or
two on additional testing before publishing the code.
1. Please suggest a place where I could put the code?
2. In what form I should give the files?
Ilija Stanislevik
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2010-02-16 8:20 Ilija Stanislevik
@ 2010-02-16 19:03 ` John Dallaway
2010-02-28 13:40 ` Ilija Stanislevik
0 siblings, 1 reply; 24+ messages in thread
From: John Dallaway @ 2010-02-16 19:03 UTC (permalink / raw)
To: Ilija Stanislevik; +Cc: eCos developers
Hi Ilija
Ilija Stanislevik wrote:
> The work on the driver is pretty much done.
Great!
> I intend to spend a day or
> two on additional testing before publishing the code.
>
> 1. Please suggest a place where I could put the code?
> 2. In what form I should give the files?
It's probably easiest to create a Bugzilla report for this. Attach the
new package as a .tar.bz2 file. Attach your changes to ecos.db and to
existing packages (if any) in the form of a plain text patch file. You
can generate the patch file using:
cd packages
cvs -q diff -u5 > ecos.patch
John Dallaway
eCos maintainer
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2010-02-16 19:03 ` John Dallaway
@ 2010-02-28 13:40 ` Ilija Stanislevik
2010-06-22 9:56 ` Ilija Stanislevik
0 siblings, 1 reply; 24+ messages in thread
From: Ilija Stanislevik @ 2010-02-28 13:40 UTC (permalink / raw)
To: John Dallaway; +Cc: eCos developers
Hi,
I just put the driver in a Bugzilla report:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000910
Awaiting comments,
Ilija Stanislevik
John Dallaway wrote:
> Hi Ilija
>
> Ilija Stanislevik wrote:
>
>
>> The work on the driver is pretty much done.
>>
>
> Great!
>
>
>> I intend to spend a day or
>> two on additional testing before publishing the code.
>>
>> 1. Please suggest a place where I could put the code?
>> 2. In what form I should give the files?
>>
>
> It's probably easiest to create a Bugzilla report for this. Attach the
> new package as a .tar.bz2 file. Attach your changes to ecos.db and to
> existing packages (if any) in the form of a plain text patch file. You
> can generate the patch file using:
>
> cd packages
> cvs -q diff -u5 > ecos.patch
>
> John Dallaway
> eCos maintainer
>
^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <894030.6104.qm@web8316.mail.in.yahoo.com>]
* Re: Ethernet over SPI driver for ENC424J600
[not found] <894030.6104.qm@web8316.mail.in.yahoo.com>
@ 2009-10-26 8:21 ` Ilija Stanislevik
0 siblings, 0 replies; 24+ messages in thread
From: Ilija Stanislevik @ 2009-10-26 8:21 UTC (permalink / raw)
To: ecos-devel
Hi Krishnan,
Yes, our application is humble enough to be satisfied with the maximum
affordable SPI bit rate, which is 14Mbps in case of ENC424J600. The bit
rate at Ethernet side can be either 10M or 100M, depending on what
pleases the network.
Ilija
Mr navaneethan krishnan wrote:
> Hi LLija
> Peoples were moving to 1gig network and with less thru put on spi even
> 100mbps itself will be difficult.
> What is an application that you want to try with SPi+ethernet
> Have you done data thruput calculations when used with SPi +ethernet.
> or , definitly needed, we appriciate your effort which will make cost
> less for ethernet core in the chip.
> K.Navaneetha Krishnan
>
>
> --- On *Mon, 10/26/09, Ilija Stanislevik /<ilijas@siva.com.mk>/* wrote:
>
>
> From: Ilija Stanislevik <ilijas@siva.com.mk>
> Subject: Ethernet over SPI driver for ENC424J600
> To: ecos-devel@ecos.sourceware.org
> Date: Monday, October 26, 2009, 6:51 AM
>
> Dear fellows,
>
> I use this opportunity to announce our development project. It is a
> driver for Microchip's ENC424J600 Ethernet controller.
>
> My company's goal is to obtain a low level Ethernet driver which will
> use standard SPI support to communicate with the Ethernet chip. The
> development is underway on STM3210E-EVAL board. We will be glad if we
> succeed to make it independent from platform and SPI hardware.
>
> Further, we plan to contribute the result of this development, as
> proposed in http://ecos.sourceware.org/contrib.html. Please advise
> us on
> the next step in this direction.
>
> Ilija Stanislevik
> SIvA doo
> ul. Zejnel Ajdini 5
> MK-1060 Skopje
> Macedonia
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Ethernet over SPI driver for ENC424J600
@ 2009-10-26 6:51 Ilija Stanislevik
2009-10-26 9:05 ` John Dallaway
0 siblings, 1 reply; 24+ messages in thread
From: Ilija Stanislevik @ 2009-10-26 6:51 UTC (permalink / raw)
To: ecos-devel
Dear fellows,
I use this opportunity to announce our development project. It is a
driver for Microchip's ENC424J600 Ethernet controller.
My company's goal is to obtain a low level Ethernet driver which will
use standard SPI support to communicate with the Ethernet chip. The
development is underway on STM3210E-EVAL board. We will be glad if we
succeed to make it independent from platform and SPI hardware.
Further, we plan to contribute the result of this development, as
proposed in http://ecos.sourceware.org/contrib.html. Please advise us on
the next step in this direction.
Ilija Stanislevik
SIvA doo
ul. Zejnel Ajdini 5
MK-1060 Skopje
Macedonia
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2009-10-26 6:51 Ilija Stanislevik
@ 2009-10-26 9:05 ` John Dallaway
2009-10-26 11:18 ` Ilija Stanislevik
2009-10-26 11:46 ` Alex Schuilenburg
0 siblings, 2 replies; 24+ messages in thread
From: John Dallaway @ 2009-10-26 9:05 UTC (permalink / raw)
To: Ilija Stanislevik; +Cc: ecos-devel
Hi Ilija
Ilija Stanislevik wrote:
> Dear fellows,
>
> I use this opportunity to announce our development project. It is a
> driver for Microchip's ENC424J600 Ethernet controller.
>
> My company's goal is to obtain a low level Ethernet driver which will
> use standard SPI support to communicate with the Ethernet chip. The
> development is underway on STM3210E-EVAL board. We will be glad if we
> succeed to make it independent from platform and SPI hardware.
>
> Further, we plan to contribute the result of this development, as
> proposed in http://ecos.sourceware.org/contrib.html. Please advise us on
> the next step in this direction.
This is great news. Thank you for letting the eCos community know of
your plans at an early stage.
This driver could be useful for many eCos developers who need to add
ethernet to an existing hardware design. I note that Microchip offers a
daughter board which includes the (similar) ENC624J600 and should make
it easy for others to start experimenting with these parts:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en543132
Are you intending to use lwIP or the FreeBSD TCP/IP stack in your
project? Regardless, I would encourage you to verify correct operation
with Simon Kallweit's port of lwIP 1.3.1:
http://download.westlicht.ch/
lwIP is a good fit for eCos and I hope lwIP 1.3.1 will be integrated in
eCos CVS soon.
At some point, you will need to complete the FSF copyright assignment
paperwork. All contributors to your driver will need to make a copyright
assignment. I would recommend getting this sorted out early to avoid
delays when the driver is ready. Full instructions are available at:
http://ecos.sourceware.org/assign.html
Finally, if you are able to collaborate with the wider eCos community on
this project, we can add it to the list of registered projects. Ref:
http://ecos.sourceware.org/contrib.html#registered
John Dallaway
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2009-10-26 9:05 ` John Dallaway
@ 2009-10-26 11:18 ` Ilija Stanislevik
2009-10-26 12:04 ` John Dallaway
2009-10-26 11:46 ` Alex Schuilenburg
1 sibling, 1 reply; 24+ messages in thread
From: Ilija Stanislevik @ 2009-10-26 11:18 UTC (permalink / raw)
To: John Dallaway; +Cc: ecos-devel
Hi John,
I have already harnessed the Microchip board with ENC624J600 to my
STM3210E-EVAL. The 424 and 624 chips are identical regarding the SPI
functionality. I plan to do most of the development on 624, till our
hardware with 424 gets ready.
We intend to use lwip.
I have sent the requirement for assignment form to gnu.org.
Please explain what will be our obligations if we decide to register
this project.
Ilija Stanislevik
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2009-10-26 11:18 ` Ilija Stanislevik
@ 2009-10-26 12:04 ` John Dallaway
2009-10-29 17:40 ` Ilija Stanislevik
0 siblings, 1 reply; 24+ messages in thread
From: John Dallaway @ 2009-10-26 12:04 UTC (permalink / raw)
To: Ilija Stanislevik; +Cc: ecos-devel
Hi Ilija
Ilija Stanislevik wrote:
> I have already harnessed the Microchip board with ENC624J600 to my
> STM3210E-EVAL. The 424 and 624 chips are identical regarding the SPI
> functionality. I plan to do most of the development on 624, till our
> hardware with 424 gets ready.
Great. Hopefully your driver will correctly initialise both parts for
operation in SPI mode with no extra effort.
> We intend to use lwip.
That's good. I envisage that the lwIP 1.3.1 stack will become popular
with eCos developers.
> Please explain what will be our obligations if we decide to register
> this project.
The main ideas behind project registration are to encourage
collaboration on new eCos components, to minimise duplicated effort and
to allow for early feedback from the eCos maintainers. With this mind,
we would expect:
a) contribution of the code to eCos CVS when it is ready (subject to
review by the eCos maintainers and copyright assignment to FSF)
b) sharing of your pre-release code with others in the eCos community on
request
c) responsiveness to feedback from the community
In fact, the lwIP 1.3.1 port is a good example of how the community can
work together in this way. There are several people already making use
of this code.
John Dallaway
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2009-10-26 12:04 ` John Dallaway
@ 2009-10-29 17:40 ` Ilija Stanislevik
2009-10-31 10:00 ` John Dallaway
0 siblings, 1 reply; 24+ messages in thread
From: Ilija Stanislevik @ 2009-10-29 17:40 UTC (permalink / raw)
To: John Dallaway, ecos-devel
John Dallaway wrote:
> The main ideas behind project registration are to encourage
> collaboration on new eCos components, to minimise duplicated effort and
> to allow for early feedback from the eCos maintainers. With this mind,
> we would expect:
>
> a) contribution of the code to eCos CVS when it is ready (subject to
> review by the eCos maintainers and copyright assignment to FSF)
>
> b) sharing of your pre-release code with others in the eCos community on
> request
>
> c) responsiveness to feedback from the community
Hi John,
We decided to register this project.
Ilija
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2009-10-29 17:40 ` Ilija Stanislevik
@ 2009-10-31 10:00 ` John Dallaway
0 siblings, 0 replies; 24+ messages in thread
From: John Dallaway @ 2009-10-31 10:00 UTC (permalink / raw)
To: Ilija Stanislevik; +Cc: ecos-devel
Ilija Stanislevik wrote:
> John Dallaway wrote:
>
>> The main ideas behind project registration are to encourage
>> collaboration on new eCos components, to minimise duplicated effort and
>> to allow for early feedback from the eCos maintainers. With this mind,
>> we would expect:
>>
>> a) contribution of the code to eCos CVS when it is ready (subject to
>> review by the eCos maintainers and copyright assignment to FSF)
>>
>> b) sharing of your pre-release code with others in the eCos community on
>> request
>>
>> c) responsiveness to feedback from the community
>
> Hi John,
>
> We decided to register this project.
Great. Thank you, Ilija.
John Dallaway
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2009-10-26 9:05 ` John Dallaway
2009-10-26 11:18 ` Ilija Stanislevik
@ 2009-10-26 11:46 ` Alex Schuilenburg
2009-10-26 21:28 ` Sergei Gavrikov
1 sibling, 1 reply; 24+ messages in thread
From: Alex Schuilenburg @ 2009-10-26 11:46 UTC (permalink / raw)
To: Ilija Stanislevik; +Cc: ecos-devel
Hi Ilija
John Dallaway wrote on 2009-10-26 09:05:
> Hi Ilija
>
> Ilija Stanislevik wrote:
>
>
>> Dear fellows,
>>
>> I use this opportunity to announce our development project. It is a
>> driver for Microchip's ENC424J600 Ethernet controller.
>>
>> My company's goal is to obtain a low level Ethernet driver which will
>> use standard SPI support to communicate with the Ethernet chip. The
>> development is underway on STM3210E-EVAL board. We will be glad if we
>> succeed to make it independent from platform and SPI hardware.
>>
>> Further, we plan to contribute the result of this development, as
>> proposed in http://ecos.sourceware.org/contrib.html. Please advise us on
>> the next step in this direction.
>>
>
> This is great news. Thank you for letting the eCos community know of
> your plans at an early stage.
>
> This driver could be useful for many eCos developers who need to add
> ethernet to an existing hardware design. I note that Microchip offers a
> daughter board which includes the (similar) ENC624J600 and should make
> it easy for others to start experimenting with these parts:
>
> http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en543132
>
> Are you intending to use lwIP or the FreeBSD TCP/IP stack in your
> project? Regardless, I would encourage you to verify correct operation
> with Simon Kallweit's port of lwIP 1.3.1:
>
> http://download.westlicht.ch/
>
> lwIP is a good fit for eCos and I hope lwIP 1.3.1 will be integrated in
> eCos CVS soon.
>
I think it is fair to advise you of the risks involved in using the
newer lwIP 1.3.1 stack and of more stable options available to you when
developing new code for eCos. Since you are developing a new device
driver, I suggest you initially stick with the FreeBSD port (and
optionally older lwIP port) which are known to work reliably, rather
than do your initial development on the newer lwIP port which is still
undergoing testing. That way at least you will ensure you are debugging
your own code initially, rather than also somebody else's.
Once you are happy with the stability of the your device driver, please
also test it against Simon's lwIP 1.3.1 port as well since it obviously
needs testers and it will most likely replace the older lwIP stack.
Please note that I am not suggesting that Simon's 1.3.1 port is unstable
or broken in any way, just that it is still relatively new and unknown
and that you ought to be aware of this when choosing which tcpip stack
to initially test your driver against.
Thanks for your notice and we look forward to seeing your contribution soon.
-- Alex Schuilenburg
Managing Director/CEO eCosCentric Limited
www.ecoscentric.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2009-10-26 11:46 ` Alex Schuilenburg
@ 2009-10-26 21:28 ` Sergei Gavrikov
2009-10-26 22:17 ` John Dallaway
0 siblings, 1 reply; 24+ messages in thread
From: Sergei Gavrikov @ 2009-10-26 21:28 UTC (permalink / raw)
To: Alex Schuilenburg; +Cc: Ilija Stanislevik, ecos-devel
On Mon, Oct 26, 2009 at 11:46:13AM +0000, Alex Schuilenburg wrote:
> John Dallaway wrote on 2009-10-26 09:05:
> > Ilija Stanislevik wrote:
> >> Dear fellows,
> >>
> >> I use this opportunity to announce our development project. It is
> >> a driver for Microchip's ENC424J600 Ethernet controller.
[snip]
Thank you!
> > This is great news. Thank you for letting the eCos community know
> > of your plans at an early stage.
[snip]
> > Are you intending to use lwIP or the FreeBSD TCP/IP stack in your
> > project? Regardless, I would encourage you to verify correct
> > operation with Simon Kallweit's port of lwIP 1.3.1:
> >
> > http://download.westlicht.ch/
[snip]
> I think it is fair to advise you of the risks involved in using the
> newer lwIP 1.3.1 stack and of more stable options available to you
> when developing new code for eCos. Since you are developing a new
> device driver, I suggest you initially stick with the FreeBSD port
> (and optionally older lwIP port) which are known to work reliably,
> rather
Hello guys, may be I miss something but I thought that any Ethernet
eCos driver is enough abstract thing to manage ETH L2 and that does
not depend (well, depends a bit) on any next layer, e.g., a TCP/IP
implementation (RedBoot TCP/IP, *BSD, lwIP* stacks) even if the driver
uses another channel (SPI) to get a memory access to MAC buffers. I
talk about generic io/eth/* stuff and..., well some kind of a future
devs/eth/mc/spi/* eth_drv_.* routines, for example. Why do you "link"
ya L2 controller with some kind of the TCP/IP? I do not understand it
enough. Will it be able to use that driver w/out interrupts in a
polling mode, i.e. to use RedBoot's TCP/IP=GDB? If it won't be, well,
that is code limits, why the lwIP 1.X.X TCP/IP only then?
Thank you for any clarifications, Regards
Sergei
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2009-10-26 21:28 ` Sergei Gavrikov
@ 2009-10-26 22:17 ` John Dallaway
2009-10-27 7:57 ` Ilija Kocho
0 siblings, 1 reply; 24+ messages in thread
From: John Dallaway @ 2009-10-26 22:17 UTC (permalink / raw)
To: Sergei Gavrikov; +Cc: ecos-devel
Hi Sergei
Sergei Gavrikov wrote:
> Hello guys, may be I miss something but I thought that any Ethernet
> eCos driver is enough abstract thing to manage ETH L2 and that does
> not depend (well, depends a bit) on any next layer, e.g., a TCP/IP
> implementation (RedBoot TCP/IP, *BSD, lwIP* stacks) even if the driver
> uses another channel (SPI) to get a memory access to MAC buffers. I
> talk about generic io/eth/* stuff and..., well some kind of a future
> devs/eth/mc/spi/* eth_drv_.* routines, for example.
In theory, of course, you are correct. The network abstractions should
ensure compatibility between any ethernet device driver and any TCP/IP
stack. But in practice, testing can reveal all manner of issues which
no-one was expecting.
We have a port of the lwIP 1.3.1 stack in development and it would
certainly be useful to test new ethernet drivers against this stack.
However, I am _not_ suggesting that the other stacks should now be
neglected.
John Dallaway
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2009-10-26 22:17 ` John Dallaway
@ 2009-10-27 7:57 ` Ilija Kocho
2009-10-27 10:08 ` Sergei Gavrikov
0 siblings, 1 reply; 24+ messages in thread
From: Ilija Kocho @ 2009-10-27 7:57 UTC (permalink / raw)
To: ecos-devel
John Dallaway wrote:
> Hi Sergei
>
> Sergei Gavrikov wrote:
>
>
>> Hello guys, may be I miss something but I thought that any Ethernet
>> eCos driver is enough abstract thing to manage ETH L2 and that does
>> not depend (well, depends a bit) on any next layer, e.g., a TCP/IP
>> implementation (RedBoot TCP/IP, *BSD, lwIP* stacks) even if the driver
>> uses another channel (SPI) to get a memory access to MAC buffers. I
>> talk about generic io/eth/* stuff and..., well some kind of a future
>> devs/eth/mc/spi/* eth_drv_.* routines, for example.
>>
>
> In theory, of course, you are correct. The network abstractions should
> ensure compatibility between any ethernet device driver and any TCP/IP
> stack. But in practice, testing can reveal all manner of issues which
> no-one was expecting.
>
This is our first eCos driver of this kind and we take the abstraction
and stack independence for granted. It may save us some effort and help
bring the driver sooner if somebody more experienced points out
potential potholes.
Regards
Ilija Kocho
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2009-10-27 7:57 ` Ilija Kocho
@ 2009-10-27 10:08 ` Sergei Gavrikov
0 siblings, 0 replies; 24+ messages in thread
From: Sergei Gavrikov @ 2009-10-27 10:08 UTC (permalink / raw)
To: Ilija Kocho; +Cc: ecos-devel
Ilija Kocho wrote:
> John Dallaway wrote:
> >Sergei Gavrikov wrote:
> >>Hello guys, may be I miss something but I thought that any
> >>Ethernet eCos driver is enough abstract thing to manage ETH L2 and
> >>that does not depend (well, depends a bit) on any next layer,
> >>e.g., a TCP/IP implementation (RedBoot TCP/IP, *BSD, lwIP* stacks)
> >>even if the driver uses another channel (SPI) to get a memory
> >>access to MAC buffers. I talk about generic io/eth/* stuff
> >>and..., well some kind of a future devs/eth/mc/spi/* eth_drv_.*
> >>routines, for example.
> >
> >In theory, of course, you are correct. The network abstractions
> >should ensure compatibility between any ethernet device driver and
> >any TCP/IP stack. But in practice, testing can reveal all manner of
> >issues which no-one was expecting.
Hello Guys,
Agreed. I just thought about those `eth_hwr_funs' for new ENC chip:
http://ecos.sourceware.org/docs-latest/ref/io-eth-drv-generic1.html
and then for start a test-path would be one from
io/eth
`-- src
|-- lwip
|-- net
|-- **newlwip**
`-- stand_alone
Of course, that will be a choice of hardware keepers. But, looking on
the picture I see why Alex suggested to go by a way without asterisks,
because, "...testing can reveal all manner of issues which no-one was
expecting" :-)
> This is our first eCos driver of this kind and we take the
> abstraction and stack independence for granted. It may save us some
> effort and help bring the driver sooner if somebody more experienced
> points out potential potholes.
Ilija, which hardware (board) do you plan to use in a development? Is
that STM3210E-EVAL? Certainly, if target has not a lot of RAM, then
choices can be `lwip' derivatives then. On the other hand, two new
fresh projects (yours enc_eth and Simon's lwip-1.3.1) would help each
other in a self testing. Keep up the good work.
Regards,
Sergei
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NAND technical review
@ 2009-10-06 13:51 Ross Younger
2009-10-07 9:40 ` Jürgen Lambrecht
0 siblings, 1 reply; 24+ messages in thread
From: Ross Younger @ 2009-10-06 13:51 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: eCos developers
Jonathan Larmour wrote:
> I think at first the ball is really in Ross/eCosCentric's court to give
> the technical rationale for the decision, so I'd like to ask him first
> to give his rationale and his own perspective of the comparison of the
> pros/cons.
Here goes with a comparison between the two in something close to their
current states (my 26/08 push to bugzilla 1000770, and Rutger's r659).
For brevity, I will refer to the two layers as "E" (eCosCentric) and "R"
(Rutger) from time to time.
Note that this is only really a comparison of the two NAND layers. I have
not attempted to compare the two YAFFS porting layers, though I do mention
them in a couple of places where it seemed relevant.
BTW: I will be off-net tomorrow and all next week, so please don't think I
am ignoring the discussion...
1. NAND 101 -------------------------------------------------------------
(Those familiar with NAND chips can skip this section, but I appreciate
that not everybody on-list is in the business of writing NAND device
drivers :-) )
(i) Conceptual
A chip comprises a number of blocks (a round power of two).
Each block comprises a number of pages (another power of two).
Each page has a "main" data area (512 or 2048 bytes on current devices) and
a "spare" - aka out-of-band or OOB - area (16 or 64 bytes respectively).
It's up to the driver and application to decide how they will use the spare
area, but it's usual for some of it to be given over to storing ECC data,
and there is space for a factory-bad marker (see below).
Programming the chip must be performed a page at a time (sometimes a 512
byte subpage).
Erasing must be performed a whole block at a time.
By way of illustration, in the chip spec sheet I have to hand (Samsung
K9F1G08 series):
* 1 page = 2k byte + 64 spare
* 1 block = 64 pages
* The whole chip has 1024 blocks, making for 128MB (1Gbit) of data and 4MB
(32Mbit) of spare area.
Now, I mentioned ECC data. NAND technology has a number of underlying
limitations, importantly that it has reliability issues. I don't have a full
picture - the manufacturers seem to be understandably coy - but my
understanding is that on each page, a driver ought to be able to cope with a
single bit having flipped either on programming or on reading. The
recommended way to achieve this is by storing an ECC in the spare area: the
algorithm published by Samsung is popular, requiring 22 bits of ECC per 256
bytes of data and able to correct a 1 bit error and detect a 2 bit error.
There is also the question of bad blocks. Again, full details are sketchy. A
chip may be shipped with a number of "factory-bad" blocks (e.g. up to 20 on
this Samsung chip); they are marked as such in their spare area. (What
constitutes a "bad" block is not published; one imagines that the factory
have access to more test information than users do and that there may be
statistical techniques involved in judging the likely reliability of the
block.) Blocks may also fail during the life of the device, usually by the
chip reporting a failure during a program or erase operation. Because of
this, the manufacturers recommend that chip drivers scan the device for
factory-bad markers then create and maintain a Bad Block Table throughout
the life of of the device. How this is done is not prescribed, but the
behaviour of the Linux MTD layer is something approximating a de facto standard.
(ii) Chip comms protocol
Getting data into and out of the chip involves a simple protocol sequence.
Commands are single bytes; addresses are sequences of a few bytes depending
on the chip size and the operation invoked.
For example, to read a page of data on the spec sheet I have to hand is:
* Write 0x00 into the command latch
* Write the four address bytes in turn into the address latch
* Write 0x30 into the command latch
* Chip signals Busy; wait for it to signal Ready
* Read out (up to) 2112 bytes of data.
However, not all chips are quite the same. The ONFI initiative is an attempt
to standardise chip protocols and most new chips should comply with it. A
number of chips on the market are _nearly_ ONFI-compliant: deviations
typically occur over the format of the ReadID response and that of an
address. I believe that older chips did their own thing entirely.
(iii) Electrical
Most, if not all, NAND chips have the same broad electrical interface.
There is a master Chip Enable line; nothing happens if this is not active.
Data flows into and out of the chip via its data bus, which is 8 or 16 bits
wide, mediated by Read Enable and Write Enable lines.
Commands and addresses are sent on the data bus, but routed to the
appropriate latches by asserting the Address Latch Enable or Command Latch
Enable lines at the same time.
There is also a ready/busy line which the driver can use to tell when an
operation is in progress. Typical operation times from the Samsung spec
sheet I have to hand are 25us for a page read, 300us for a page program, and
2ms for a block erase.
(iv) Board hook-up
What's more interesting is how the lines are hooked up to the board.
It is quite commonplace for a board based on a SoC to make good use of an
onboard memory controller or dedicated NAND controller. This allows the
controller to be programmed with the electrical profile the chip expects,
which makes life easy for the device driver: often, you just have to write
bytes to the relevant MMIO register address as fast as you wish and the
controller takes care of the rest.
If the NAND lines are connected to the CPU only as GPIO, the driver has a
lot of work to do in conforming to the correct signal profile at every step
of the chip protocol. (I haven't had to produce such a port, and I don't
think Rutger has needed one either, though he has produced an untested
example driver.)
In the case of a dedicated NAND controller, it is common to provide
hardware-assistance for ECC calculation. Where available, this provides a
significant speed-up (about 40% per page in my benchmarking).
Sometimes the ready/busy line isn't wired in or requires a jumper to be set
to route it. This can be worked around: for a read operation, one can just
insert a delay loop for the prescribed maximum time, while for programs and
erases, most (all?) chips have a "Read Status" command which can be used to
query whether the operation has completed.
It can be beneficial to be able to set up the ready/busy line as an
interrupt source, as opposed to having to poll it. Whilst there is an
overhead involved in context-switching, if other application threads have
much to do it may be advantageous overall for the thread waiting for the
NAND to sleep until woken by interrupt.
Of course, it is possible to put multiple chips on a board. In that case
there needs to be a way to route between them; I would expect this to be
done with the Chip Select line, addressed either by different MMIO addresses
or a separate GPIO or CPLD step. Theoretically, multiple chips could be
hooked up in parallel to give something that looks like a 16 or 32-bit
"wide" chip, but I have never encountered this in the NAND world, and it
would impose a certain extra level of complexity on the driver.
2. Application interface -----------------------------------------------
Both layers have broadly similar application interfaces.
In both layers, an application must first use a `lookup' call which provides
a pointer to a device context struct. In Rutger's layer, devices are
identified by device number; in eCosCentric's, by a textual name set in the
board HAL.
Both layers provide a means of finding out about the device. R's provides
a call which returns an info block; E's provides macros which retrieve
information from the device struct (which may also be queried directly).
The basic operations required are reading a page, programming a page and
erasing a block, and both layers provide these.
The page-oriented operations optionally allow read/write of the page spare
area. These operations also automatically calculate and check an ECC, if the
device has been configured to do so. Rutger's layer has an extra hook in
place where an application may explicitly request the use of cached reading
and writing where the device supports this.
Both layers also support the necessary ancillary operations of querying the
status of a block in the bad-block table, and marking a block as bad.
(a) Partitions
E's application interface also provides logic implementing partitions.
That is to say, all access to a NAND array must be via a `partition';
the NAND layer sanity-checks whether the requested flash page or block
address is within the given partition. This is quite a lightweight
layer and hasn't added much overhead of either code footprint or
execution time.
The presence of partitions in E's model was controversial, as are its
fine details. Nevertheless, some notion of partitioning turns out to be
essential on some boards. In some recent work for a customer we identified
three separate regions of NAND: somewhere to put the boot loader (primary,
as booted by ROM, and RedBoot), somewhere for the application image itself
(perhaps FIS-like rather than a full filesystem), and a filesystem for the
application to use as it pleases.
R's interface does not have such a facility. It appears that, in the event
that the flash is shared between two or more logical regions, it's up to
higher-level code to be configured with the correct block ranges to use.
(b) Dynamic memory allocation
R's layer mandates the provision of malloc and free, or compatible
functions. These must be provided to the cyg_nand_init() call.
E's doesn't; instead it declares a small number of static buffers.
Andrew Lunn opined on 6/3/09 that R's requirement for malloc is not a major
issue because the memory needs of that layer are well-bounded; I think I
broadly agree, though the situation is not ideal in that it forces somebody
who wants to use a lean, mean eCos configuration to work around.
Also note that if you're going to run a full file system like YAFFS, you
can't avoid needing malloc, but in an application making simpler use of
NAND, it's an overhead that you may prefer to avoid.
3. Driver model --------------------------------------------------------
The major architectural difference between the two NAND layers is in their
driver models and the degree of abstraction enforced.
In Rutger's layer, controllers and chips are both formally abstracted. The
application talks to the Abstract NAND Chip, which has (hard-coded) the
basic sequences of commands, addresses and data required to talk to a NAND
chip. This layer talks to a controller driver, which provides the nuts and
bolts of reading and writing to the device. The chip driver is also called
by the ANC layer, and provides the really chip-specific parts.
The call flow looks something like this (best viewed in fixed-width font):
Application --(H)-> ANC --(L)-> Controller driver
\
\-(C)-> Chip driver
H: high-level interface (read page, program page, erase block; chip
(de)selection)
L: low-level interface (read/write commands, addresses, data; query the busy
line)
C: chip-specific details (chip init, parse ReadID, query factory-bad marker)
In eCosCentric's layer, a NAND driver is a single abstraction covering chip
init and querying the factory-bad status as well as the high level functions
(reading a page, etc). It is left to the driver to determine the sequence of
commands to send. How the driver interacts with the device is considered to
be a contract only between the driver and the relevant platform HAL, so is
not formally abstracted by the NAND layer.
E's chip drivers are written as .inl files, intended to be included by the
relevant platform HALs by whichever source file provides the required
low-level functions. The lack of a formal abstraction is an attempt to
provide a leaner and meaner experience at runtime: the low-level functions
can be (and indeed are, so far) provided as static inlines.
The flow looks like this:
Application --(H1)-> NAND layer --(H2)-> NAND driver --(L*)-> Platform HAL
H1: high-level calls (read page, program page, erase block)
H2: high-level calls (as H1, plus device init and query factory-bad marker)
L*: low-level calls, like L above but not formally abstracted
The two models have pros and cons in both directions.
- As hinted at above, the static inline model of E's low-level access
functions is expected to turn out to have a lower function call (and,
generally, code size) overhead than R's.
- R's model shares the command sequence logic amongst all chips,
differentiating only between small- and large-page devices. (I do not know
whether this is correct for all current chips, though going forwards seems
less likely to be an issue as fully-ONFI-compliant chips become the norm.)
If multiple chips of different types are present in a build, E's model
potentially duplicates code (though this could be worked around; also, an
ONFI driver ought to be written).
- A corollary of arguably inconsequential import: R's model forces the synth
driver to emulate an entire NAND chip and its protocol. E's synth doesn't
need to.
- E's high-level driver interface makes it harder to add new functions
later, necessitating a change to that API (H2 above). R's does not; the
requisite logic would only need to be added to the ANC. It is not thought
that more than a handful such changes will ever be required, and it may be
possible to maintain backwards compatibility. (As a case in point, support
for hardware ECC is currently work-in-progress within eCosCentric, and does
require such a change, but now is not the right time to discuss that.)
It would perhaps be interesting to compare the complexities of drivers for
the two models, but it's not readily apparent how we would do that fairly.
Perhaps porting a driver from one NAND layer to the other would be a useful
exercise, and would also allow us to compare code sizes. Any suggestions or
(he says hopefully) volunteers? I've got a lot on my plate this month...
4. Feature/implementation differences ------------------------------------
(I don't consider these to be significant issues; whilst noteworthy, I don't
think they would take much effort to resolve.)
(a) Documentation
The two layers' documentation differ in their depth and layout; these are
difficult for me to compare objectively, and I would suggest that a fresh
pair of eyes compare them.
I can only offer the comment that I documented the E layer bearing in mind
what I considered to be missing from the R layer documentation: it was not
clear how the controller and chip layers inter-related, nor where to start
in creating a driver. (I also had a lot less experience of NAND chips then
than I do now, and what I need to know now is different from what a newbie
would.)
(b) Availability of drivers
R provides support for:
- One board: BlackFin EZ-Kit BF548 (which is not in anoncvs?)
- One chip: the ST Micro 0xG chip (large page, x8 and x16 present but
presumably only tested on the x8 chip on the BlackFin board?)
- A synthetic controller/chip package
- A template for a GPIO-based controller (untested, intended as an example only)
I seem to remember rumours of the existence of a driver for a further
chip+board combination, but I haven't seen it.
E provides support for:
- Two boards: Embedded Artists LPC2468 (very well tested); STM3210E (largely
complete, based on work by Simon K; some enhancements planned)
- Two chips: Samsung K9 family (large page, only x8 done so far); ST-Micro
NANDxxxx3A (small page, x8) (based on work by Simon K)
- Synthetic target. This offers more features than R's: bad block injection,
logging, and a GUI interface via the synth I/O auxiliary.
- Further (customer-confidential) board ports.
(c) RedBoot support
E have added some commands for NAND operations and tested on the EA LPC2468
board. (YAFFS support works via the existing RB fileio layer; nothing really
needed to be done.)
(d) Degree of testing
There are presumably differences of coverage here; both E and R assert they
have carried out stress tests. Properly comparing the depth of the two would
be a job for fresh eyes.
E have:
- a handful of unit and functional tests of the NAND layer, and a benchmarker
- a number of YAFFS functional tests, one of which includes benchmarking,
and a further severe YAFFS stress test: these indirectly test the NAND
layer. (The latter has been run under the synth driver with bad-block
injection turned on, and has revealed some subtle bugs which we probably
wouldn't otherwise have caught.)
- the ability to run continual test cycles in their test farm
5. Works in progress -----------------------------------------------------
I can of course only comment on eCosCentric's plans, but the following work
is in the pipeline:
* Expansion of the device interface to better allow efficient hardware ECC
support (in progress)
* Hardware ECC for the STM3210E board driver
* Performance tuning of software ECC and of NAND low-level drivers
* Partition addressing: make addressing relative to the start of the
partition, once and for all
* Simple raw NAND "filesystem" for use by RedBoot (see
http://ecos.sourceware.org/ml/ecos-devel/2009-07/msg00004.html et seq; those
are the latest public mails but not the latest version of my thinking, which
I will update in due course)
* More RedBoot NAND utility commands
* Support for booting Linux off NAND and for sharing a (YAFFS) NAND-resident
filesystem
* Part-page read support (would provide a big speed-up to parts of YAFFS2
inbandTags mode as needed by small-page devices like that on the STM3210E)
--------------------------------------------------------------------------
Ross
--
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071. www.ecoscentric.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: NAND technical review
2009-10-06 13:51 NAND technical review Ross Younger
@ 2009-10-07 9:40 ` Jürgen Lambrecht
2009-10-13 2:44 ` Jonathan Larmour
0 siblings, 1 reply; 24+ messages in thread
From: Jürgen Lambrecht @ 2009-10-07 9:40 UTC (permalink / raw)
To: Ross Younger, Rutger Hofman
Cc: Jonathan Larmour, eCos developers, Deroo Stijn
Ross Younger wrote:
> Jonathan Larmour wrote:
>
>> I think at first the ball is really in Ross/eCosCentric's court to give
>> the technical rationale for the decision, so I'd like to ask him first
>> to give his rationale and his own perspective of the comparison of the
>> pros/cons.
>>
>
> Here goes with a comparison between the two in something close to their
> current states (my 26/08 push to bugzilla 1000770, and Rutger's r659).
> For brevity, I will refer to the two layers as "E" (eCosCentric) and "R"
> (Rutger) from time to time.
>
> Note that this is only really a comparison of the two NAND layers. I have
> not attempted to compare the two YAFFS porting layers, though I do mention
> them in a couple of places where it seemed relevant.
>
> BTW: I will be off-net tomorrow and all next week, so please don't think I
> am ignoring the discussion...
>
<snip>
> (a) Partitions
>
> E's application interface also provides logic implementing partitions.
> That is to say, all access to a NAND array must be via a `partition';
> the NAND layer sanity-checks whether the requested flash page or block
> address is within the given partition. This is quite a lightweight
> layer and hasn't added much overhead of either code footprint or
> execution time.
>
> The presence of partitions in E's model was controversial, as are its
> fine details. Nevertheless, some notion of partitioning turns out to be
> essential on some boards. In some recent work for a customer we identified
> three separate regions of NAND: somewhere to put the boot loader (primary,
> as booted by ROM, and RedBoot), somewhere for the application image itself
> (perhaps FIS-like rather than a full filesystem), and a filesystem for the
> application to use as it pleases.
>
>
> R's interface does not have such a facility. It appears that, in the event
> that the flash is shared between two or more logical regions, it's up to
> higher-level code to be configured with the correct block ranges to use.
>
>
> (b) Dynamic memory allocation
>
> R's layer mandates the provision of malloc and free, or compatible
> functions. These must be provided to the cyg_nand_init() call.
>
> E's doesn't; instead it declares a small number of static buffers.
>
> Andrew Lunn opined on 6/3/09 that R's requirement for malloc is not a major
> issue because the memory needs of that layer are well-bounded; I think I
> broadly agree, though the situation is not ideal in that it forces somebody
> who wants to use a lean, mean eCos configuration to work around.
>
> Also note that if you're going to run a full file system like YAFFS, you
> can't avoid needing malloc, but in an application making simpler use of
> NAND, it's an overhead that you may prefer to avoid.
>
>
> 3. Driver model --------------------------------------------------------
>
> The major architectural difference between the two NAND layers is in their
> driver models and the degree of abstraction enforced.
>
> In Rutger's layer, controllers and chips are both formally abstracted. The
> application talks to the Abstract NAND Chip, which has (hard-coded) the
> basic sequences of commands, addresses and data required to talk to a NAND
> chip. This layer talks to a controller driver, which provides the nuts and
> bolts of reading and writing to the device. The chip driver is also called
> by the ANC layer, and provides the really chip-specific parts.
>
> The call flow looks something like this (best viewed in fixed-width font):
>
> Application --(H)-> ANC --(L)-> Controller driver
> \
> \-(C)-> Chip driver
>
> H: high-level interface (read page, program page, erase block; chip
> (de)selection)
> L: low-level interface (read/write commands, addresses, data; query the busy
> line)
> C: chip-specific details (chip init, parse ReadID, query factory-bad marker)
>
>
> In eCosCentric's layer, a NAND driver is a single abstraction covering chip
> init and querying the factory-bad status as well as the high level functions
> (reading a page, etc). It is left to the driver to determine the sequence of
> commands to send. How the driver interacts with the device is considered to
> be a contract only between the driver and the relevant platform HAL, so is
> not formally abstracted by the NAND layer.
>
> E's chip drivers are written as .inl files, intended to be included by the
> relevant platform HALs by whichever source file provides the required
> low-level functions. The lack of a formal abstraction is an attempt to
> provide a leaner and meaner experience at runtime: the low-level functions
> can be (and indeed are, so far) provided as static inlines.
>
> The flow looks like this:
>
> Application --(H1)-> NAND layer --(H2)-> NAND driver --(L*)-> Platform HAL
>
> H1: high-level calls (read page, program page, erase block)
> H2: high-level calls (as H1, plus device init and query factory-bad marker)
> L*: low-level calls, like L above but not formally abstracted
>
>
> The two models have pros and cons in both directions.
>
> - As hinted at above, the static inline model of E's low-level access
> functions is expected to turn out to have a lower function call (and,
> generally, code size) overhead than R's.
>
> - R's model shares the command sequence logic amongst all chips,
> differentiating only between small- and large-page devices. (I do not know
> whether this is correct for all current chips, though going forwards seems
> less likely to be an issue as fully-ONFI-compliant chips become the norm.)
> If multiple chips of different types are present in a build, E's model
> potentially duplicates code (though this could be worked around; also, an
> ONFI driver ought to be written).
>
> - A corollary of arguably inconsequential import: R's model forces the synth
> driver to emulate an entire NAND chip and its protocol. E's synth doesn't
> need to.
>
> - E's high-level driver interface makes it harder to add new functions
> later, necessitating a change to that API (H2 above). R's does not; the
> requisite logic would only need to be added to the ANC. It is not thought
> that more than a handful such changes will ever be required, and it may be
> possible to maintain backwards compatibility. (As a case in point, support
> for hardware ECC is currently work-in-progress within eCosCentric, and does
> require such a change, but now is not the right time to discuss that.)
>
>
>
Therefore we prefer R's model.
Is it possible that R's model follows better the "general" structure of
drivers in eCos?
I mean: (I follow our CVS, could maybe differ from the final commit of
Rutger to eCos)
1. with the low-level chip-specific code in /devs
(devs/flash/arm/at91/[board] and devs/flash/arm/at91/nfc, and
devs/flash/micron/nand)
2. with the "middleware" in /io (io/flash_nand/current/src and there
/anc, /chip, /controller)
3. with the high-level code in /fs
Is it correct that R's abstraction makes it possible to add partitioning
easily?
(because that is an interesting feature of E's implementation)
We also prefer R's model of course because we started with R's model and
use it now.
> It would perhaps be interesting to compare the complexities of drivers for
> the two models, but it's not readily apparent how we would do that fairly.
>
> Perhaps porting a driver from one NAND layer to the other would be a useful
> exercise, and would also allow us to compare code sizes. Any suggestions or
> (he says hopefully) volunteers? I've got a lot on my plate this month...
>
same for us, no time now - beginning of next year?
>
> 4. Feature/implementation differences ------------------------------------
>
> (I don't consider these to be significant issues; whilst noteworthy, I don't
> think they would take much effort to resolve.)
>
> (a) Documentation
>
> The two layers' documentation differ in their depth and layout; these are
> difficult for me to compare objectively, and I would suggest that a fresh
> pair of eyes compare them.
>
> I can only offer the comment that I documented the E layer bearing in mind
> what I considered to be missing from the R layer documentation: it was not
> clear how the controller and chip layers inter-related, nor where to start
> in creating a driver. (I also had a lot less experience of NAND chips then
> than I do now, and what I need to know now is different from what a newbie
> would.)
>
> (b) Availability of drivers
>
> R provides support for:
> - One board: BlackFin EZ-Kit BF548 (which is not in anoncvs?)
>
- Two: also our "automatic announcement" board to store mp3's with an
Atmel ARM9 AT91SAM9260 with 16MB of SDRAM.
> - One chip: the ST Micro 0xG chip (large page, x8 and x16 present but
> presumably only tested on the x8 chip on the BlackFin board?)
>
- Two: also the Micron MT29F2G08AACWP-ET:D 256MB 3V3 NAND FLASH (2kB
page size, x8)
Because if this chip, Rutger adapted the hardware ECC controller code,
because our chip uses more bits (for details, ask Stijn or Rutger).
> - A synthetic controller/chip package
> - A template for a GPIO-based controller (untested, intended as an example only)
>
> I seem to remember rumours of the existence of a driver for a further
> chip+board combination, but I haven't seen it.
>
> E provides support for:
> - Two boards: Embedded Artists LPC2468 (very well tested); STM3210E (largely
> complete, based on work by Simon K; some enhancements planned)
> - Two chips: Samsung K9 family (large page, only x8 done so far); ST-Micro
> NANDxxxx3A (small page, x8) (based on work by Simon K)
> - Synthetic target. This offers more features than R's: bad block injection,
> logging, and a GUI interface via the synth I/O auxiliary.
> - Further (customer-confidential) board ports.
>
> (c) RedBoot support
>
> E have added some commands for NAND operations and tested on the EA LPC2468
> board. (YAFFS support works via the existing RB fileio layer; nothing really
> needed to be done.)
>
> (d) Degree of testing
>
> There are presumably differences of coverage here; both E and R assert they
> have carried out stress tests. Properly comparing the depth of the two would
> be a job for fresh eyes.
>
> E have:
> - a handful of unit and functional tests of the NAND layer, and a benchmarker
> - a number of YAFFS functional tests, one of which includes benchmarking,
> and a further severe YAFFS stress test: these indirectly test the NAND
> layer. (The latter has been run under the synth driver with bad-block
> injection turned on, and has revealed some subtle bugs which we probably
> wouldn't otherwise have caught.)
> - the ability to run continual test cycles in their test farm
>
We have it very well tested, amongst others
- an automatic (continual) nand-flash test in a clima chamber
- stress tests: putting it full over and over again via FTP (both with
af few big and many small files) and check the heap remaining:
* Put 25 files with a filesize of 10.000.000 bytes on the filesystem
* Put 2500 files with a filesize of 100.000 bytes on the filesystem
* Put 7000 files with a filesize of 10.000 bytes on the filesystem
Conclusion: storing smaller files needs more heap, but we still have
plenty left with our 16MB
* Write a bundle of files over and over again on the filesystem. We
put everytime 1000 files of 100.000 bytes filesize on the flash drive.
- used in the final mp3-player application
Kind regards,
Jürgen
>
> 5. Works in progress -----------------------------------------------------
>
> I can of course only comment on eCosCentric's plans, but the following work
> is in the pipeline:
>
> * Expansion of the device interface to better allow efficient hardware ECC
> support (in progress)
> * Hardware ECC for the STM3210E board driver
> * Performance tuning of software ECC and of NAND low-level drivers
> * Partition addressing: make addressing relative to the start of the
> partition, once and for all
> * Simple raw NAND "filesystem" for use by RedBoot (see
> http://ecos.sourceware.org/ml/ecos-devel/2009-07/msg00004.html et seq; those
> are the latest public mails but not the latest version of my thinking, which
> I will update in due course)
> * More RedBoot NAND utility commands
> * Support for booting Linux off NAND and for sharing a (YAFFS) NAND-resident
> filesystem
> * Part-page read support (would provide a big speed-up to parts of YAFFS2
> inbandTags mode as needed by small-page devices like that on the STM3210E)
>
> --------------------------------------------------------------------------
>
>
> Ross
>
> --
> Embedded Software Engineer, eCosCentric Limited.
> Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
> Registered in England no. 4422071. www.ecoscentric.com
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NAND technical review
2009-10-07 9:40 ` Jürgen Lambrecht
@ 2009-10-13 2:44 ` Jonathan Larmour
2009-10-13 12:59 ` Rutger Hofman
0 siblings, 1 reply; 24+ messages in thread
From: Jonathan Larmour @ 2009-10-13 2:44 UTC (permalink / raw)
To: Jürgen Lambrecht
Cc: Ross Younger, Rutger Hofman, eCos developers, Deroo Stijn
Jürgen Lambrecht wrote:
> Ross Younger wrote:
>> - E's high-level driver interface makes it harder to add new functions
>> later, necessitating a change to that API (H2 above). R's does not; the
>> requisite logic would only need to be added to the ANC. It is not thought
>> that more than a handful such changes will ever be required, and it
>> may be
>> possible to maintain backwards compatibility. (As a case in point,
>> support
>> for hardware ECC is currently work-in-progress within eCosCentric, and
>> does
>> require such a change, but now is not the right time to discuss that.)
>
> Therefore we prefer R's model.
>
> Is it possible that R's model follows better the "general" structure of
> drivers in eCos?
> I mean: (I follow our CVS, could maybe differ from the final commit of
> Rutger to eCos)
> 1. with the low-level chip-specific code in /devs
> (devs/flash/arm/at91/[board] and devs/flash/arm/at91/nfc, and
> devs/flash/micron/nand)
> 2. with the "middleware" in /io (io/flash_nand/current/src and there
> /anc, /chip, /controller)
> 3. with the high-level code in /fs
I don't see E's model as being much different in that perspective. There
is stuff in devs/flash, io/nand and (presumably) fs as well.
The difference is more the separation out of the controller functionality
into a different layer.
> Is it correct that R's abstraction makes it possible to add partitioning
> easily?
> (because that is an interesting feature of E's implementation)
As Rutger said, it could be done - there's nothing in his design which
presents it. It's not there now though, so unless someone's working on it
it's probably not something to consider in the decision process.
Especially since it would be a big user API change.
> We also prefer R's model of course because we started with R's model and
> use it now.
You haven't done any profiling by any luck have you? Or code size
analysis? Although I haven't got into the detail of R's version yet (since
I was starting with dissecting E's), both the footprint and the cumulative
function call and indirection time overhead are concerns of mine.
>> (b) Availability of drivers
[snip]
>> - One chip: the ST Micro 0xG chip (large page, x8 and x16 present but
>> presumably only tested on the x8 chip on the BlackFin board?)
>>
>
> - Two: also the Micron MT29F2G08AACWP-ET:D 256MB 3V3 NAND FLASH (2kB
> page size, x8)
> Because if this chip, Rutger adapted the hardware ECC controller code,
> because our chip uses more bits (for details, ask Stijn or Rutger).
I'd be interested in what the issue was. From admittedly a quick look I
can't find anything about this in the code.
>> (d) Degree of testing
[snip]
> We have it very well tested, amongst others
> - an automatic (continual) nand-flash test in a clima chamber
> - stress tests: putting it full over and over again via FTP (both with
> af few big and many small files) and check the heap remaining:
> * Put 25 files with a filesize of 10.000.000 bytes on the filesystem
> * Put 2500 files with a filesize of 100.000 bytes on the filesystem
> * Put 7000 files with a filesize of 10.000 bytes on the filesystem
> Conclusion: storing smaller files needs more heap, but we still have
> plenty left with our 16MB
> * Write a bundle of files over and over again on the filesystem. We put
> everytime 1000 files of 100.000 bytes filesize on the flash drive.
> - used in the final mp3-player application
That's extremely useful to know, thanks! But a couple of further questions
on this: Did any bad blocks show up at any point? Were you using a bad
block table? Presumably there were factory-marked bad blocks on some?
Thanks,
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NAND technical review
2009-10-13 2:44 ` Jonathan Larmour
@ 2009-10-13 12:59 ` Rutger Hofman
2009-10-15 4:41 ` Jonathan Larmour
0 siblings, 1 reply; 24+ messages in thread
From: Rutger Hofman @ 2009-10-13 12:59 UTC (permalink / raw)
To: Jonathan Larmour
Cc: Jürgen Lambrecht, Ross Younger, eCos developers, Deroo Stijn
Jonathan Larmour wrote:
[snip]
>> We also prefer R's model of course because we started with R's model
>> and use it now.
>
> You haven't done any profiling by any luck have you? Or code size
> analysis? Although I haven't got into the detail of R's version yet
> (since I was starting with dissecting E's), both the footprint and the
> cumulative function call and indirection time overhead are concerns of
> mine.
In a first step in mitigating the 'footprint pressure', I have added CDL
options to configure in/out support for the various chips types, to wit:
- ONFI chips;
- 'regular' large-page chips;
- 'regular' small-page chips.
It is in r678 on my download page
(http://www.cs.vu.nl/~rutger/software/ecos/nand-flash/). As I had
suggested before, this was a very small refactoring (although code has
moved about in io_nand_chip.c to save on the number of #ifdefs).
One more candidate for a reduce in code footprint: I can add a CDL
option to configure out support for heterogeneous controllers/chips. The
ANC layer will become paper-thin then. If this change will make any
difference, I will do it within, say, a week's time.
As regards the concerns for (indirect) function call overhead: my
intuition is that the NAND operations themselves (page read, page write,
block erase) will dominate. It takes 200..500us only to transfer a page
over the data bus to the NAND chip; one recent data sheet mentions
program time 200us, erase time 1.5ms. I think only a very slow CPU would
show the overhead of less than 10 indirect function calls.
Rutger
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NAND technical review
2009-10-13 12:59 ` Rutger Hofman
@ 2009-10-15 4:41 ` Jonathan Larmour
2009-10-19 10:53 ` Ross Younger
0 siblings, 1 reply; 24+ messages in thread
From: Jonathan Larmour @ 2009-10-15 4:41 UTC (permalink / raw)
To: Rutger Hofman
Cc: Jürgen Lambrecht, Ross Younger, eCos developers, Deroo Stijn
Rutger Hofman wrote:
> Jonathan Larmour wrote:
> [snip]
>
>>> We also prefer R's model of course because we started with R's model
>>> and use it now.
>>
>>
>> You haven't done any profiling by any luck have you? Or code size
>> analysis? Although I haven't got into the detail of R's version yet
>> (since I was starting with dissecting E's), both the footprint and the
>> cumulative function call and indirection time overhead are concerns of
>> mine.
>
>
> In a first step in mitigating the 'footprint pressure', I have added CDL
> options to configure in/out support for the various chips types, to wit:
> - ONFI chips;
> - 'regular' large-page chips;
> - 'regular' small-page chips.
> It is in r678 on my download page
> (http://www.cs.vu.nl/~rutger/software/ecos/nand-flash/). As I had
> suggested before, this was a very small refactoring (although code has
> moved about in io_nand_chip.c to save on the number of #ifdefs).
I'm sure that's useful.
> One more candidate for a reduce in code footprint: I can add a CDL
> option to configure out support for heterogeneous controllers/chips. The
> ANC layer will become paper-thin then. If this change will make any
> difference, I will do it within, say, a week's time.
I wouldn't want you to spend time until the decision's made. I'll make a
note that it would take a week to do. Admittedly, I'm not sure the savings
would be enough to make it "paper-thin".
> As regards the concerns for (indirect) function call overhead: my
> intuition is that the NAND operations themselves (page read, page write,
> block erase) will dominate. It takes 200..500us only to transfer a page
> over the data bus to the NAND chip; one recent data sheet mentions
> program time 200us, erase time 1.5ms. I think only a very slow CPU would
> show the overhead of less than 10 indirect function calls.
I think it's more the cumulative effect, primarily on reads. Especially as
there's no asynchronous aspect - the control process is synchronous, so
any delays between real underlying NAND operations only add up. Ross
quoted an example of about 25us for a page read. Off the top of my head,
for something like a 64MHz CPU with 4 clock ticks per instruction on
average, that's 16 insns per us, so a page read is about equivalent to 400
insns. At that sort of level I'm not sure overheads are lost in the noise.
Maybe I've messed up those guestimates though.
I wonder if Ross has any performance data for E he could contribute?
On a separate point, while I'm here, I think the use of printf via
cyg_nand_global.pf would want tidied up a lot. Some of them seem to be
there to mention errors to the user, but without any programmatic
treatment of the errors, primarily reporting them to higher layers.
It should also be possible to eliminate the overheads of the printf. Right
now there's quite a lot of them, involving function calls, allocation of
const string data, and occasionally calculation of arguments, even if the
pf function pointer is pointing to an empty null printf function. It
should be possible to turn them off entirely, and not be any worse off for
it (including error reporting back up to higher layers). It might not be
so bad if the strings were a lot shorter, or the printf functions less
frequently used, but being able to turn them off entirely would seem better.
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NAND technical review
2009-10-15 4:41 ` Jonathan Larmour
@ 2009-10-19 10:53 ` Ross Younger
2009-10-20 1:40 ` Jonathan Larmour
0 siblings, 1 reply; 24+ messages in thread
From: Ross Younger @ 2009-10-19 10:53 UTC (permalink / raw)
To: Jonathan Larmour
Cc: Rutger Hofman, Jürgen Lambrecht, eCos developers, Deroo Stijn
Jonathan Larmour wrote:
> I wonder if Ross has any performance data for E he could contribute?
I have done a little benchmarking and so have _some_ numbers to hand, but
the goalposts are moving and my figures are a bit old and must be treated
with caution...
On the EA LPC2468 board (Samsung K9 NAND chip), with the state of my code on
July 8, compiling with -O2 and asserts off, my NAND benchmarker reported
average page read times[*] of 3578us per page, programming 2680us, and
erasing 1848us. These stack up against the fastest-possible raw chip times
(which I computed from the "typical" times on the datasheet) of 88.5, 363.5
and 2000us.
[*] full page (2k) plus OOB
This led to a YAFFS throughput data rate, on a recently-erased NAND array,
of up to 480kB/s in reading and 578kB/s in writing. (Actual rates vary
depending on the size of chunk you pass to read() and write().)
It seems worthwhile to share numbers for the customer port I've been working
on; not because they're of direct use to the eCos project, but to show what
a difference the hardware makes.
The board is based on the Samsung S3C2410X ucontroller and carries the same
Samsung K9 NAND chip as on the EA LPC2468. Now, this CPU has a dedicated
NAND controller with hardware ECC... After I taught the library to use h/w
ECC I immediately saw a 46% speedup on reads and 38% on writes when compared
with software ECC. I've also added an option to do a partial loop unroll in
the read and write cycles which gives a further 4% boost on reads and 15% on
writes. The current (work-in-progress) numbers I have from the benchmarker
are 452us per page read, 623us per write and 1934us per erase; YAFFS
throughput is similarly impressive at 4690 kB/s in reads and 3432 kB/s in
writes. (Charles Manning has stated publicly several times that if you want
YAFFS to be fast, you should start by looking at the speed of your NAND driver.)
Of course, we're not comparing apples with apples here; the S3C2410X is an
ARM9 whose CPU clock runs at 200MHz, but the EA LPC2468 is an ARM7TDMI
running at just 48MHz, but even so the speed-up given by hardware ECC
demonstrates that option to be a no-brainer.
BTW: Some profiling and souping up is on my todo list, and some more
benchmarking will probably happen at that time. When I implement hardware
ECC support on the STM3210E I intend to produce some before and after numbers.
Ross
--
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071. www.ecoscentric.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NAND technical review
2009-10-19 10:53 ` Ross Younger
@ 2009-10-20 1:40 ` Jonathan Larmour
2009-10-20 10:17 ` Ross Younger
0 siblings, 1 reply; 24+ messages in thread
From: Jonathan Larmour @ 2009-10-20 1:40 UTC (permalink / raw)
To: Ross Younger
Cc: Rutger Hofman, Jürgen Lambrecht, eCos developers, Deroo Stijn
Ross Younger wrote:
> Jonathan Larmour wrote:
>
>>I wonder if Ross has any performance data for E he could contribute?
>
> I have done a little benchmarking and so have _some_ numbers to hand, but
> the goalposts are moving and my figures are a bit old and must be treated
> with caution...
>
> On the EA LPC2468 board (Samsung K9 NAND chip), with the state of my code on
> July 8, compiling with -O2 and asserts off, my NAND benchmarker reported
> average page read times[*] of 3578us per page, programming 2680us, and
> erasing 1848us. These stack up against the fastest-possible raw chip times
> (which I computed from the "typical" times on the datasheet) of 88.5, 363.5
> and 2000us.
To double check, you mean reading was slowest, programming was faster and
erasing was fastest, even apparently faster than what may be the
theoretical fastest time? (I use the term "fast" advisedly, mark).
Are you sure there isn't a problem with your driver to cause such figures? :-)
> This led to a YAFFS throughput data rate, on a recently-erased NAND array,
> of up to 480kB/s in reading and 578kB/s in writing. (Actual rates vary
> depending on the size of chunk you pass to read() and write().)
I wonder if Rutger has the ability to compare with his YAFFS throughput.
OTOH, as you say, the controller plays a large part, and there's no common
ground with R so it's entirely possible no comparison can be fair for
either implementation.
> The board is based on the Samsung S3C2410X ucontroller and carries the same
> Samsung K9 NAND chip as on the EA LPC2468. Now, this CPU has a dedicated
> NAND controller with hardware ECC... After I taught the library to use h/w
> ECC I immediately saw a 46% speedup on reads and 38% on writes when compared
> with software ECC. I've also added an option to do a partial loop unroll in
> the read and write cycles which gives a further 4% boost on reads and 15% on
> writes.
Just to be sure, are the differences measured by these percentages purely
in terms of overall data throughput per time?
I'm very interested in the fact that software changes you made, had such a
relatively large change to the performance. If that's true, this seems to
go against the possibility that waiting for hardware (the NAND chip) may
have figured as the dominating component of the time (which would mean the
software components of the overall time are lost in the noise). Instead
the software latency required in setting up the next operation can be
noticeable - which was my concern with R in my mail of 2009-10-15 which
you're replying to.
> The current (work-in-progress) numbers I have from the benchmarker
> are 452us per page read, 623us per write and 1934us per erase; YAFFS
> throughput is similarly impressive at 4690 kB/s in reads and 3432 kB/s in
> writes. (Charles Manning has stated publicly several times that if you want
> YAFFS to be fast, you should start by looking at the speed of your NAND driver.)
Hmm, as opposed to what though? YAFFS itself isn't able to change much.
> Of course, we're not comparing apples with apples here; the S3C2410X is an
> ARM9 whose CPU clock runs at 200MHz, but the EA LPC2468 is an ARM7TDMI
> running at just 48MHz, but even so the speed-up given by hardware ECC
> demonstrates that option to be a no-brainer.
Hence my surprise at E not having support, even in principle, before! But
clearly you're at the stage where stuff is nearly working. I look forward
to a code drop, as the APIs would benefit from comparison with R's. It
looks like R has considered a variety of interesting ECC hardware so it
would be interesting to see if E's could cope.
> BTW: Some profiling and souping up is on my todo list, and some more
> benchmarking will probably happen at that time. When I implement hardware
> ECC support on the STM3210E I intend to produce some before and after numbers.
Just as an aside, you may find that improving eCos more generally to have
e.g. assembler optimised implementation of memcpy/memmove/memset (and
possibly others) may improve performance of these and other things across
the board. GCC's intrinsics can only do so much. (FAOD actual
implementations to use (at least to start with) can be found in newlib.
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NAND technical review
2009-10-20 1:40 ` Jonathan Larmour
@ 2009-10-20 10:17 ` Ross Younger
2009-10-21 2:06 ` Jonathan Larmour
0 siblings, 1 reply; 24+ messages in thread
From: Ross Younger @ 2009-10-20 10:17 UTC (permalink / raw)
To: Jonathan Larmour
Cc: Rutger Hofman, Jürgen Lambrecht, eCos developers, Deroo Stijn
Jonathan Larmour wrote:
> To double check, you mean reading was slowest, programming was faster
> and erasing was fastest, even apparently faster than what may be the
> theoretical fastest time? (I use the term "fast" advisedly, mark).
>
> Are you sure there isn't a problem with your driver to cause such
> figures? :-)
Those are the raw numbers. Yes, I agree that they don't appear to make
sense. As I said, profiling - which will include figuring out what's going
on here - is languishing on the todo list ...
> I wonder if Rutger has the ability to compare with his YAFFS throughput.
> OTOH, as you say, the controller plays a large part, and there's no
> common ground with R so it's entirely possible no comparison can be fair
> for either implementation.
The YAFFS benchmarking is done by our yaffs5 test, which IIRC goes only
through fileio so ought to be trivially portable. It doesn't appear in my
last drop on the bz ticket, but will when I get round to freshening it.
>> After I taught the library to use h/w
>> ECC I immediately saw a 46% speedup on reads and 38% on writes when
>> compared with software ECC [...]
>
> Just to be sure, are the differences measured by these percentages
> purely in terms of overall data throughput per time?
These are from my raw NAND benchmarks (tests/rwbenchmark.c) which measure
the end-to-end time taken for a whole cyg_nand_page_read() / write /
block_erase call to return.
> I'm very interested in the fact that software changes you made, had such
> a relatively large change to the performance.
> [hardware ECC]
> Hence my surprise at E not having support, even in principle, before!
> But clearly you're at the stage where stuff is nearly working.
I was surprised too; but then I had been operating under the general mantra
of "first make it work, then make it work fast" and the speed work is still
in progress ...
To be clear: hwecc _is_ working well, on this customer port, and getting it
going on the STM3210E is on the cards so I have something I can usefully
share publicly.
> Just as an aside, you may find that improving eCos more generally to
> have e.g. assembler optimised implementation of memcpy/memmove/memset
> (and possibly others) may improve performance of these and other things
> across the board. GCC's intrinsics can only do so much. (FAOD actual
> implementations to use (at least to start with) can be found in newlib.
The speedups in my NAND driver on this board came from a straightforward
Duff's device 8-way-unroll of what had been HAL_{READ,WRITE}_UINT8_VECTOR;
16-way and 32-way unrolls seemed to add a smidgen more performance but
increased code size perhaps disproportionately. (Using the existing VECTOR
macro but with -funroll-loops gave a similar speed-up but more noticeable
code bloat across the board.)
The word copies in newlib's memcpy et al look like they would boost
performance generally, but I have attempted to avoid copying data around as
far as possible in my layer. I don't see them as helping at all with NAND
device access: you have to make a sequence of 8-bit or 16-bit writes to the
MMIO register, and that's that. This is pretty much the same situation as
Tom Duff found himself in ...
To try and fit with the eCos philosophy, I've left the localised unroll as a
CDL option in this driver, defaulting to off. I expect similar unrolls would
be profitable in other NAND drivers, but a more generalised solution might
be preferable: something like HAL_READ_UINT8_VECTOR_UNROLL, with options to
configure whether and how far it was unrolled?
Ross
--
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071. www.ecoscentric.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NAND technical review
2009-10-20 10:17 ` Ross Younger
@ 2009-10-21 2:06 ` Jonathan Larmour
2009-10-22 10:05 ` Ross Younger
0 siblings, 1 reply; 24+ messages in thread
From: Jonathan Larmour @ 2009-10-21 2:06 UTC (permalink / raw)
To: Ross Younger; +Cc: Rutger Hofman, eCos developers
Ross Younger wrote:
> Jonathan Larmour wrote:
>
>>To double check, you mean reading was slowest, programming was faster
>>and erasing was fastest, even apparently faster than what may be the
>>theoretical fastest time? (I use the term "fast" advisedly, mark).
>>
>>Are you sure there isn't a problem with your driver to cause such
>>figures? :-)
>
>
> Those are the raw numbers. Yes, I agree that they don't appear to make
> sense. As I said, profiling - which will include figuring out what's going
> on here - is languishing on the todo list ...
Ok, although I think I may have to take those particular figures with a
pinch of salt, given they are.... unexpected.
>>I wonder if Rutger has the ability to compare with his YAFFS throughput.
>>OTOH, as you say, the controller plays a large part, and there's no
>>common ground with R so it's entirely possible no comparison can be fair
>>for either implementation.
>
>
> The YAFFS benchmarking is done by our yaffs5 test, which IIRC goes only
> through fileio so ought to be trivially portable. It doesn't appear in my
> last drop on the bz ticket, but will when I get round to freshening it.
Ok. Although I'm not sure how long these discussions will continue for.
Although not ideal, running it on both the synth targets may be the only
way to compare.
> To be clear: hwecc _is_ working well, on this customer port, and getting it
> going on the STM3210E is on the cards so I have something I can usefully
> share publicly.
Can you at least shed light on the API changes (by cut'n'pasting relevant
sections of headers/code even if not the whole thing)? I feel this is a
key thing to get clarity on since I don't have a view on that yet and it's
an important feature. I know doc etc. will want updating, but in reality
we can probably get a good idea from an overview of the code, even if it's
not a complete self-contained package drop. It may also save you time. I
don't doubt it works on your port, but I think I need to get a view on how
well it would fit with other hardware ECC systems which I know about and
those which R goes to pains to support.
I also realise people have busy lives so no worries if you can't do it for
a few days if there's more than a little effort involved; although I'd
have thought it wouldn't be much.
>>Just as an aside, you may find that improving eCos more generally to
>>have e.g. assembler optimised implementation of memcpy/memmove/memset
>>(and possibly others) may improve performance of these and other things
>>across the board. GCC's intrinsics can only do so much. (FAOD actual
>>implementations to use (at least to start with) can be found in newlib.
>
>
> The speedups in my NAND driver on this board came from a straightforward
> Duff's device 8-way-unroll of what had been HAL_{READ,WRITE}_UINT8_VECTOR;
> 16-way and 32-way unrolls seemed to add a smidgen more performance but
> increased code size perhaps disproportionately. (Using the existing VECTOR
> macro but with -funroll-loops gave a similar speed-up but more noticeable
> code bloat across the board.)
OOI you could add it to the per-package CFLAGS (unless you meant you
already did and the bloat was noticeable even just there).
> The word copies in newlib's memcpy et al look like they would boost
> performance generally, but I have attempted to avoid copying data around as
> far as possible in my layer.
I was mostly thinking of YAFFS in fact (and fileio on top), although I
haven't really looked at the extent they depend on bulk memory moves.
> To try and fit with the eCos philosophy, I've left the localised unroll as a
> CDL option in this driver, defaulting to off. I expect similar unrolls would
> be profitable in other NAND drivers, but a more generalised solution might
> be preferable: something like HAL_READ_UINT8_VECTOR_UNROLL, with options to
> configure whether and how far it was unrolled?
Possible, although there are probably bigger fish to fry.
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NAND technical review
2009-10-21 2:06 ` Jonathan Larmour
@ 2009-10-22 10:05 ` Ross Younger
2009-11-10 5:15 ` Jonathan Larmour
0 siblings, 1 reply; 24+ messages in thread
From: Ross Younger @ 2009-10-22 10:05 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Rutger Hofman, eCos developers
Jonathan Larmour wrote:
> Can you at least shed light on the API changes (by cut'n'pasting
> relevant sections of headers/code even if not the whole thing)?
I have changed the device interface (nand_device.h) by carving up the read
and write page functions into three. (The prototype changes are the same for
both, with only the obvious semantic differences when writing, so I'll only
paste in read for the sake of brevity.)
Reading a page used to be an all-in-one call:
int (*read_page) (cyg_nand_device *dev, cyg_nand_page_addr page,
void * dest, size_t size, void * spare, size_t spare_size);
Now, the NAND layer calls "begin" once to set up the read:
int (*read_begin)(cyg_nand_device *dev, cyg_nand_page_addr page);
... "stride" one or more times to actually transfer data
int (*read_stride)(cyg_nand_device *dev, void * dest, size_t size);
... and then "finish" once to do the spare area and any finishing up that
may be necessary (e.g. send the "program confirm" command, unlock the device).
int (*read_finish)(cyg_nand_device *dev,
void * spare, size_t spare_size);
The ECC interface (nand_ecc.h, not well documented) has also expanded
slightly. I had had just a 'calc' call, but have now added an 'init' call so
that any device-specific registers can be tweaked. The interaction is
perhaps best sketched out as pseudocode; here's what the NAND library looks
like in a call to read a page:
dev->read_begin(page number);
while (there are still bytes to send) {
ecc->init(); // may be a no-op
dev->read_stride(ecc->datasize bytes);
if (ecc is hardware)
ecc->calc(the block we've just read);
}
dev->read_finish(spare data);
if (ecc is software)
ecc->calc(the whole thing);
ecc->repair(the whole block, looping as necessary, comparing the
calculated ECC against what's in the spare area);
I have renamed the device interface struct and macros on the grounds of
"change the interface, change the name" (but not the ECC interface, because
nothing outside that package had used it before now).
>> [-funroll-loops]
> OOI you could add it to the per-package CFLAGS (unless you meant you
> already did and the bloat was noticeable even just there).
Good point, I forgot about that. Will try when I get back around to the
go-faster stripes.
Ross
--
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071. www.ecoscentric.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NAND technical review
2009-10-22 10:05 ` Ross Younger
@ 2009-11-10 5:15 ` Jonathan Larmour
2009-11-10 10:38 ` Ross Younger
0 siblings, 1 reply; 24+ messages in thread
From: Jonathan Larmour @ 2009-11-10 5:15 UTC (permalink / raw)
To: Ross Younger; +Cc: Rutger Hofman, eCos developers
[ Sorry all for the loss of momentum. Real life intervened for a while. ]
Ross Younger wrote:
> Jonathan Larmour wrote:
>
>>Can you at least shed light on the API changes (by cut'n'pasting
>>relevant sections of headers/code even if not the whole thing)?
>
>
> I have changed the device interface (nand_device.h) by carving up the read
> and write page functions into three. (The prototype changes are the same for
> both, with only the obvious semantic differences when writing, so I'll only
> paste in read for the sake of brevity.)
>
> Reading a page used to be an all-in-one call:
>
> int (*read_page) (cyg_nand_device *dev, cyg_nand_page_addr page,
> void * dest, size_t size, void * spare, size_t spare_size);
>
> Now, the NAND layer calls "begin" once to set up the read:
>
> int (*read_begin)(cyg_nand_device *dev, cyg_nand_page_addr page);
>
> ... "stride" one or more times to actually transfer data
>
> int (*read_stride)(cyg_nand_device *dev, void * dest, size_t size);
>
> ... and then "finish" once to do the spare area and any finishing up that
> may be necessary (e.g. send the "program confirm" command, unlock the device).
>
> int (*read_finish)(cyg_nand_device *dev,
> void * spare, size_t spare_size);
>
> The ECC interface (nand_ecc.h, not well documented) has also expanded
> slightly. I had had just a 'calc' call, but have now added an 'init' call so
> that any device-specific registers can be tweaked. The interaction is
> perhaps best sketched out as pseudocode; here's what the NAND library looks
> like in a call to read a page:
>
> dev->read_begin(page number);
> while (there are still bytes to send) {
> ecc->init(); // may be a no-op
> dev->read_stride(ecc->datasize bytes);
> if (ecc is hardware)
> ecc->calc(the block we've just read);
> }
> dev->read_finish(spare data);
> if (ecc is software)
> ecc->calc(the whole thing);
> ecc->repair(the whole block, looping as necessary, comparing the
> calculated ECC against what's in the spare area);
>
>
> I have renamed the device interface struct and macros on the grounds of
> "change the interface, change the name" (but not the ECC interface, because
> nothing outside that package had used it before now).
This seems reasonable at first glance. But to double check.... if you have
an SoC with both built-in NFC and hardware ECC, it may be able to calc the
ECC automatically as the pages are read/written through the NFC. What you
can then get with reads is a direct result of whether the ECC has failed,
whether it's recoverable or not. You don't have to actually look at the
ECC value itself at any point. This is what Rutger calls ECC "syndrome"
mode, which isn't a very descriptive term, but OTOH I can't think of
anything much better either!). You can consider the Atmel SAM9260 to be a
concrete example if that helps (although in that particular case you can
see the actual computed ECC too - but (R) implies that that may not always
be the case for reads).
So can you just confirm that (E) supports that form of hardware ECC
implementation? Or does it actually require the ECC to be directly
available (as opposed to potentially just being a token)? I also note with
the SAM9260 that the hardware ECC registers get wiped if you start to
read/write another page, so can you confirm or otherwise that no other
NAND API user can cause that to happen in (E)? The SAM9260 also requires
you to read the entire page data, followed immediately by the spare area
locations where the ECC is stored. Is that also supportable by (E)?
It does seem that it is supported by (R), albeit complicated by the
abstracted scatter-gather spare layout management.
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NAND technical review
2009-11-10 5:15 ` Jonathan Larmour
@ 2009-11-10 10:38 ` Ross Younger
2009-11-10 11:28 ` Ethernet over SPI driver for ENC424J600 Ilija Stanislevik
0 siblings, 1 reply; 24+ messages in thread
From: Ross Younger @ 2009-11-10 10:38 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: Rutger Hofman, eCos developers
> [syndrome]
> So can you just confirm that (E) supports that form of hardware ECC
> implementation?
I've just googled up the outline of syndrome mode (which seems,
incidentally, to be at least a de facto standard term). I don't see any
reason I couldn't fit it in given my current hooks.
> I also note
> with the SAM9260 that the hardware ECC registers get wiped if you start
> to read/write another page, so can you confirm or otherwise that no
> other NAND API user can cause that to happen in (E)?
The standard per-device locking provided by (E) will take care of this. If
there is a risk of concurrent access to other devices causing problems it's
trivial to add a further board-level lock in the driver.
> The SAM9260 also
> requires you to read the entire page data, followed immediately by the
> spare area locations where the ECC is stored. Is that also supportable
> by (E)?
It looks like that's standard for syndrome-type ECC. I think this is just a
funny OOB area layout, though as ever I'd have to try it and see to be sure.
Ross
(PS. BTW, I am still working on that fresh anon-based drop I promised the
other week, but am trying to find out why the benchmarks are so screwy on
the EA LPC2468 before I finish cutting the drop. And - speaking of ECC -
sitting in my pile of queued commits I have a major speed-up in software ECC
calculation...)
--
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071. www.ecoscentric.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Ethernet over SPI driver for ENC424J600
2009-11-10 10:38 ` Ross Younger
@ 2009-11-10 11:28 ` Ilija Stanislevik
2009-11-10 12:16 ` Chris Holgate
0 siblings, 1 reply; 24+ messages in thread
From: Ilija Stanislevik @ 2009-11-10 11:28 UTC (permalink / raw)
To: eCos developers
Hi all,
I am developing the driver on STM32 platform and my intention is to make
it independent of platform.
The driver makes use of external interrupt (from one of the general
purpose I/O pins in case of STM32) to get interrupt request from
Ethernet chip. I've found that, in eCos 3.0 implementation for STM32,
the cyg_drv_interrupt_... functions don't set up the AFIO_EXTICRx
register, which is necessary in order to connect particular I/O pin with
the EXTI logic. The driver can always arrange for this outside the
standard functions, but such an approach produces a driver which is tied
not only to Ethernet chip, but to platform too.
I wish if some of cyg_drv_interrupt_...() could arrange the whole
external interrupt signal train based solely on the interrupt vector
given to it. This is possible for STM32, since interrupt vectors bear
unambiguous info on the assigned GPIO pin. Are there plans to provide
such functionality?
Another solution is external function provided from application within
the private data structure, to be called from drivers init function. The
driver is still platform-independent and the application programmer
should take care for marshaling of interrupt.
Thoughts or suggestions?
Ilija Stanislevik
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Ethernet over SPI driver for ENC424J600
2009-11-10 11:28 ` Ethernet over SPI driver for ENC424J600 Ilija Stanislevik
@ 2009-11-10 12:16 ` Chris Holgate
0 siblings, 0 replies; 24+ messages in thread
From: Chris Holgate @ 2009-11-10 12:16 UTC (permalink / raw)
To: Ilija Stanislevik; +Cc: eCos developers
Hi Ilija,
Ilija Stanislevik wrote:
> The driver makes use of external interrupt (from one of the general
> purpose I/O pins in case of STM32) to get interrupt request from
> Ethernet chip. I've found that, in eCos 3.0 implementation for STM32,
> the cyg_drv_interrupt_... functions don't set up the AFIO_EXTICRx
> register, which is necessary in order to connect particular I/O pin with
> the EXTI logic. The driver can always arrange for this outside the
> standard functions, but such an approach produces a driver which is tied
> not only to Ethernet chip, but to platform too.
I think that it's the general case that when using external interrupts
there will be some form of platform specific setup, so it's good idea to
isolate this anyway.
> Another solution is external function provided from application within
> the private data structure, to be called from drivers init function. The
> driver is still platform-independent and the application programmer
> should take care for marshaling of interrupt.
Rather than adding a callback in the private data structure, you can add
the external interrupt setup to your platform specific initialisation
code and then just include the interrupt vector ID in the private area
of your SPI device data structure. Once the generic driver knows the
vector ID it can then take care of managing the interrupt itself.
Chris.
--
Christopher J. Holgate
Thinking Of The Future @ Zynaptic Limited (www.zynaptic.com)
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2010-06-22 9:56 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-03 9:37 Ethernet over SPI driver for ENC424J600 Ilija Stanislevik
2010-02-03 13:13 ` Simon Kallweit
2010-02-04 9:17 ` John Dallaway
2010-02-05 7:59 ` Ilija Stanislevik
2010-02-05 8:16 ` Ilija Kocho
2010-02-05 10:26 ` Ross Younger
-- strict thread matches above, loose matches on Subject: below --
2010-02-16 8:20 Ilija Stanislevik
2010-02-16 19:03 ` John Dallaway
2010-02-28 13:40 ` Ilija Stanislevik
2010-06-22 9:56 ` Ilija Stanislevik
[not found] <894030.6104.qm@web8316.mail.in.yahoo.com>
2009-10-26 8:21 ` Ilija Stanislevik
2009-10-26 6:51 Ilija Stanislevik
2009-10-26 9:05 ` John Dallaway
2009-10-26 11:18 ` Ilija Stanislevik
2009-10-26 12:04 ` John Dallaway
2009-10-29 17:40 ` Ilija Stanislevik
2009-10-31 10:00 ` John Dallaway
2009-10-26 11:46 ` Alex Schuilenburg
2009-10-26 21:28 ` Sergei Gavrikov
2009-10-26 22:17 ` John Dallaway
2009-10-27 7:57 ` Ilija Kocho
2009-10-27 10:08 ` Sergei Gavrikov
2009-10-06 13:51 NAND technical review Ross Younger
2009-10-07 9:40 ` Jürgen Lambrecht
2009-10-13 2:44 ` Jonathan Larmour
2009-10-13 12:59 ` Rutger Hofman
2009-10-15 4:41 ` Jonathan Larmour
2009-10-19 10:53 ` Ross Younger
2009-10-20 1:40 ` Jonathan Larmour
2009-10-20 10:17 ` Ross Younger
2009-10-21 2:06 ` Jonathan Larmour
2009-10-22 10:05 ` Ross Younger
2009-11-10 5:15 ` Jonathan Larmour
2009-11-10 10:38 ` Ross Younger
2009-11-10 11:28 ` Ethernet over SPI driver for ENC424J600 Ilija Stanislevik
2009-11-10 12:16 ` Chris Holgate
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).