In thinking how to write this up, I just discovered more of a mystery, which perhaps still needs addressing (pun intended?).
When Rolf did the original lwip port, he wrote "To leave more RAM to the application it shares the network RAM space with the lowlevel driver (..., AHBSRAM1 on LPC1768)."
This can be seen in his version of lwipopts.h:
#define MEM_POSITION __attribute((section("AHBSRAM1"),aligned))
Igor's post here clarifies that AHBSRAM1 is indeed the memory reserved for ethernet.
In Donatien's lwipopts.h, for some reason he has switched to using AHBSRAM0 (this is the space reserved for USB):
#define MEM_POSITION __attribute((section("AHBSRAM0")))
Perhaps this is to avoid clashes between the low level ethernet RAM required and that used by the networking stack code, so it was easier to separate them between AHBSRAM0 and AHBSRAM1. It does beg the question though, how much space is free in AHBSRAM1 and why can't it be used, when you have a project that needs to use AHBSRAM0 for USB (or other purposes).
To the specific problem with the 5 Aug 2010 version of the networking stack, I think this has occurred because Donatien has upgraded to a later version of the core lwip code, and not put the MEM_POSITION macros back in the core files mem.c and memp.c. If you go back to Donatien's 11 Jun 2010 version (using an earlier version of the core lwip code), you'll see the right place for MEM_POSITION (once in mem.c and three times in memp.c).
Making these changes to the 5 Aug 2010 code and recompiling results in the main RAM usage dropping to 3.6 kB (at the expense of AHBSRAM0 RAM of course).
I would still ask though, can the networking stack revert to making use of AHBSRAM1 as with Rolf's original port or was there a good reason to switch to AHBSRAM0?
I would also ask that we get some indication of RAM usage in AHBSRAM0 and AHBSRAM1 after a compilation (hence the reason to keep this discussion on this thread about memory reporting). Simon wrote "I agree we could make it more comprehensive, but hopefully this is a start!" Can I suggest now is a good time; I spent quite a few hours tracking down this issue in Donatien's code and it would have been immediately obvious with a view of the AHB RAM usage alongside the main RAM. I also want to use AHB RAM for other things (like my scmRTOS stacks and data acquisition buffers), so I would really like to be able to manage it carefully. RAM is the most precious resource on the mbed, and I don't share Simon's view above that "we don't count the AHB RAM under this analysis, as that is a bit specialist". I'm just a noob, and I'm asking for it (again after this experience), so that should be a good reason ;-). Could it at least be an option when viewing the build statistics (off by default to avoid confusion)? Is this too late to add before the beta goes live?
I'm trying to get an idea of how much RAM my code and libraries are using; it seems different on both code and libraries depending on whether I compile with the beta on or not. I know there is an issue with AHB reporting but I am not sure that can account for it all. Please see the post here; I'm confused about the amount of RAM claimed to be in use by the libraries when using the latest ethernet stack - if in the beta the AHB RAM is no longer used then it doesn't seem right.