This is the mail archive of the ecos-discuss@sourceware.org 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: RedBoot ROM resource management after loading RAM eCos application.


At 05:12 AM 2/21/2006, Andrew Lunn wrote:
Yes, it needs some RAM. Normally redboot provides the hal diag tty
communication channel, gdb talks to redboot, etc. It needs RAM to do
this. The linker script is setup so that Redboot gets the lowest part
of RAM and the application is loaded above this. eg

[snip]


This raises another interesting point.

For grins & giggles i tried building and then loading the "simple application" from the book on my system and Redboot complained that it couldn't load because doing so would cause it to commit suicide. Basically, on the i386 platform, when you've selected GRUB as a startup for Redboot, Redboot loads at 0x00108000 which is the same address that applications attempt to load. Presumably there is some way to tell the linker to re-locate application to 0x00110000 or somewhere else "above" Redboot. Alternatively (and this is that tack I'll work on once the Ethernet driver is done to my satisfaction) is a Redboot that can run in the first 640K of RAM such that I could have applications load at 0x00100000 and work things that way. It appears that by default the lower 1M on the i386 platform is basically wasted. (I thought of putting my heap there but the heap really belongs at the "end" of RAM growing down.) (Oh, and I hacked it to manually link at 0x002000000 and loaded it and ran it to see that, yes, it did in fact run.)

Then another thing that came up is that Redboot seems to prefer the serial port for doing diagnostics. Redboot does open up a diagnostics console on ethernet as well (port 9000 by default) and one can connect GDB through that port. If I wanted to have by ethernet driver "pretend" it was two ethernet devices such that Redboot could continue to use one for its diagnostic use and I could use it for my application. Where would I plug that in? It does not look to terribly difficult to create a "pseudo" ethernet driver which I can link into the "real" ethernet driver by a bit of CDL. In particular using, as a mandatory option, of the pseudo ethernet the name of the real ethernet that is backing it. By adding a couple of options, one to do multiple mac pretending (real nic is in promiscuous mode but only passing up packets with the identified mac address). And device configuration. It seems I could build a redboot that did this. Anyone else tried something similar or would this be breaking new ground?

--Chuck


-- 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]