Conference decwet::nt-developers

3181.0. "internal bus address translation..." by MLWS::LICHT (Meir Licht, 882-3231) Wed Jan 29 1997 08:46

    I'll start with a simple question followed by a more broader
    description.

    Question: On Alpha, will HalTranslateBusAddress do a translation when
    called with physical address that falls within the range of the
    system's local memory (and  interface_type = Internal, busNumber = 0,
    addressspace = 0,).

    I have tried that on two different Alpha systems, and
    HalTranslateBusAddress returned FALSE. I was told that on WNT/Intel
    it works.

    more details:

    A custome is considering using some amount of the systems memory.
    The method that the customer is successfully using on WNT/Intel is:

    1 - use MAXMEM (OR BURMEMORY on Alpha) to limit the amount of memory
    that will be used by the OS.

    2 - Tries to allocate memory resource by successive calls to
    IoReportResourceUsage with different physical address. This is the
    first location where the code fails on Alpha with the following
    messages:

     IoTranslateResourceList: address could not be translated
     IoReportResourceUsage: Bad resource list being translated
     Module Unload: LOCAL_IM_1.SYS
     [SC] 5e: ScLoadDeviceDriver: NtLoadDriver(local_im_1) Failed 0xc000000d
     NETAPI32: [SCSTUB] NetServiceInstall:StartService failed 87

    3 - After succesfull memory resource allocation a call is made to
    HalTranslateBusAddress followed by conditional call to MmIoMapIoSpace.

    Any help will be appreciated,
    Meir

    Re .0, i'll have to look it up, but i don't think InterfaceType of
    Internal is supported on Alpha NT (similarly, a host of others such as
    TurboChannel, NuBus, etc.).  Are you trying to use a physical range of
    system memory as a "Drop Off" location for kernel drivers to share
    data?
    
    --svb

    
    There is adual use
    
    1-Possible use of the host's memory instead of placing memory on a PCI
    custom board, having the board and the driver and user mode code
    access the memory. The memory size (future) that we're talking about
    is in the access of several hundreads of MBytes.
    
    2-development of the application (usermode and k-drivers) before full
    blown PCI custom boards exists.
    
    Any ideads ?
    
    ML
    

    Re .2, have you looked into the PrestoServe adapter?  Its largest model
    is an 8 MB PCI NVRAM board.  Instead of building your own custom board,
    buying/using the PrestoServe is probably a better deal.  Despite its
    small capacity, it may come in handy for building your user/kernel
    codes while waiting for the full blown PCI adapter.
    
    --svb