This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Standalone ethernet application


Nick Garnett wrote:
Jonathan Larmour <jifl@eCosCentric.com> writes:

Haven't really looked, but this happens when the ring of rx buffers in the PCI window is corrupt. It's possible a BIOS setting could do this, or a card problem. But my suspicion is that your standalone program may be using more than 640K of RAM, leaving insufficient room for the PCI window.


This seems to be the problem. note that the first ring buffer that
fails is at 0x000a0a9c, just above the 640k line. It looks like
somewhere along the way, the i82559 driver has been configured to use
a full 1M of buffer space by default, without considering the PC
platform. It seems that this has been here for a long time, and it was
sheer luck that it has worked. It seems that the checking that Andrew
added in October has brought it to light.

Ah, didn't notice it used as much as 1M... that pretty obviously screws it up.


The simplest thing to do is to reduce the values of MAX_RX_DESCRIPTORS
and MAX_TX_DESCRIPTORS when running in the PC floppy boot
configuration.

I'll take a look at fixing this.

Hmm, yes, because it will affect redboot. I don't see how this could ever have worked for long before in fact, as surely you would move into the bogus memory before too long.


The default should arguably be lower too - the comment in i82559_info.h is solely from this driver's origins from the ebsa. Certainly the comment is wrong anywhere other than ARMs or possibly sa110s specifically even.

This is because the "FLOPPY" startup type is, by itself,
only really intended for redboot. You should probably tweak the memory
layout in hal/i386/pc/current/include/pkgconf/mlt_i386_pc_floppy* to
take advantage of memory above 0x100000. RAM startup apps
automatically load and run above 0x100000 which is why those don't
normally have a problem.

A better alternative for stand-alone apps is to use the GRUB
option. This loads the application above the 1M line.

It's still a bit of a restriction that FLOPPY startup stuff doesn't even know of the existence of any memory above 640k. Twould be nicer to map away the 640k->1M block to a different location to avoid the "hole", but if we want to execute BIOS interrupts, that could be a problem. But what about remapping all but a few pages of RAM above 1M? If we're already having to artificially divide memory above 1M and below 640k with no easy consolidation, using a little more for page tables doesn't seem onerous.


Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
>>>>> Visit us in booth 2527 at the Embedded Systems Conference 2004 <<<<<
March 30 - April 1, San Francisco http://www.esconline.com/electronicaUSA/
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine


-- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]