Hi Jamie
Although (probably) possible I don't think that this will work that well due to 2 reasons.
1. The Ethernet controller can be configured to use a certain buffer size (128 bytes up to 1.5k). It fixes 2 rx buffers and 1 tx buffer of this size in memory. I think that it is possible to block the use of one of the rx buffers but the fact is that its memory is fixed at the start of RAM so the system memory (starting after the end of the tx buffer) is not contiguous to this freed RAM.
Certain variables could of course be forced there under control of the linker script.
2. Having only one rx buffer will result in dropped rx frames whenever 2 are received faster than the TCP/IP stack can handle the first frame. This will probably result in high level of losses and repetitions in the system and so is not advisable - as noted above, it is (probably) possible to block one of the rx buffer by simply not freeing it for use by the EMAC.
This fact explains the reason why the EMAC uses 2 rx buffers and 1 tx buffer. The tx buffer is not critical since it is filled by software and nothing is lost when the SW is a bit slow. The rx buffers are however critical and that is why 2 are available so that the EMAC can be filling the second while the SW is still 'consuming' the first.
Note that, although you have defined 1k buffers, it is your software which is controlling the use of the tx buffer. If you know that the largest frame that you send will be, say, 256 bytes you can still link the project to start putting its system variables at 0x900 (overlapping the Tx EMAC buffer space) rather than at 0xc00. Only your SW writes to this buffer (not the EMAC controller) so this may be a possibility to gain a bit of RAM.
Don't forget also to use the functions fnStackFree(), fnHeapAvailable() and fnHeapFree() to monitor allocation ad actual use of memory. You may find that the space reserved for heap can be reduced.
Good luck
Regards
Mark