lkml.org 
[lkml]   [2004]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: HELP: Linux replacement for "DOS diagnostic" station
Date
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [from the cache]
©2003-2011 Jasper Spaans