[lkml]   [2004]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: HELP: Linux replacement for "DOS diagnostic" station
    On Monday 08 March 2004 17:17, Timothy Miller wrote:
    > Like many companies that do hardware development (PCI cards, etc.), when
    > we here first produce a board, the first things we do is put it into a
    > DOS machine and run our diagnostic tools on it. We're running the DOS
    > version that came with Windows 3.11, and we use the Watcom C compiler
    > that lets us run our software in protected mode, so we have access to
    > 32-bit address space.
    > Some advantages of this approach:
    > - Single-tasking environment, so we can do polling on devices in real-time
    > - No memory protection, so we can access all device memory directly
    > - No instruction set restrictions, so we can execute I/O instructions
    > directly
    > - Access to PCI config space (via I/O instructions)
    > - The computer boots up in seconds
    > Disadvantages include:
    > - No modern compiler
    > - No debugging tools
    > - DOS command shell is a lousy working environment
    > - Dwindling support for DOS NIC drivers from motherboard manufacturers
    > We are doing some forward-looking thinking about how we're going to
    > replace this environment in the not-to-distant future. We are looking
    > at Linux as the environment we want to use. Some of the features we're
    > thinking of include:
    > - Kernel support for basically nothing but Ethernet, text-mode console,
    > and USB (ie. IDE and floppy not necessarily supported).
    > - Boot from USB flash dongle.
    > - Hand-code init so that services are loaded in parallel
    > - Fill the rest of the USB dongle with development tools
    > - Put the rest of the tools on NFS.
    > There are a number of issues that we have to cover (such as what
    > filesystem to use on the flash and how to make the flash bootable), but
    > the biggest concern is that we absolutely MUST have un restricted access
    > to physical memory, I/O space, and config space from user-space programs.
    > So, first of all, we need to make /dev/mem accessible to all users.
    > Secondly, we need some mechanism to access I/O and config space, but it
    > can be indirect through ioctl.
    > Is there a driver for Linux which supports I/O and config space access
    > for user-space programs in a completely generic way?
    > Another occurrence is that sometimes, PCI config space on a new device
    > is 'broken' and therefore confuses the OS trying to map it. We'll need
    > to be able to override the OS in a way that doesn't interfere with other
    > devices. That is, we need to (a) indicate which device NOT to map, (b)
    > query which memory areas have been allocated to other devices, and (c)
    > program in our own desired physical addresses into config space.
    > Does anyone have suggestions?
    > Thanks!

    Just a brief one:

    I suggest using one of the embeded kernels. For your purpose it has the
    following advantages:
    1. no MMU support - allows your applications to poke at ANYTHING.
    2. ramdisk support - eliminates the kernel from interfereing with most PCI
    tests you can do. (granted, you MIGHT want a system with two PCI busses, one
    for the system to use -disk/keyboard/display/network and one for your target
    interface; but I think you can get away from this using an AGP display, the
    keyboard/mouse and ramdisk)
    3. minimal system
    4. development on another host
    5. safty from inevitable crashes/bus hangs...
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:01    [W:0.028 / U:16.604 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site