David Fernandez <[EMAIL PROTECTED]> writes: > Hi there, > > I'm doing an application based in the Redboot code, and I've got a > couple of questions: > > - The hal_tables.h definitions for > sections .ecos.table.xxx.begin, ...finish. Are they treated in some > special way by the linker, or are they just taking advantage of some > alphanumeric ordering performed by the linker to become efectyvely the > begining and end of each table?
Just alphanumeric ordering. The suffixes .begin, .entry, .extra and .finish were chosen so that the linker's sorting would put them in correct order. > > - The CYGMEM_REGION_pci_window, seems to have been defined just to > provide a memory pool for the ethernet driver ring buffers. Is there any > reason why that was designed that way so different than the others? The PCI bus hardware needs to be set up with an aperture from the PCI bus address space into the CPU physical address space. This PCI window region is where that aperture points. It means that the DMA engines in the ethernet device can be given PCI space addresses that correspond to addresses in this window. There are often limitations to the size and alignment of the aperture, so it is not always possible to just map all of RAM and use arbitrary addresses. > > - Do anyone know about some problems with some particular drivers if > trying to integrate them the same way the ethernet drivers were wrapped > into RedBoot? What drivers? Not all device drivers are able to function in a polled-only environment. The ethernet drivers were specifically designed to make this work. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts
