[forum] want to be a hardware developer ?

[Vladimir Dergachev <volodya@mindspring.com>]

There had been several complaints from potential developers that register
specs are not available.

While register specs are useful, I believe that people that complain about
their lack have not had experience with datasheets for
vendor-manufacturered hardware (I was in this position once too).

Unlike public specifications for chips like bt848 - which are rather
detailed and contain tons of information besides register addresses, many
specifications that I worked with are far less detailed.

For example, it could be that for most of the registers only the addresses
and the names of particular bitfields are known - nothing more. It is up
to the developer to figure out how the hardware works by writing trial
values and determining which bits do what and in what sequence they have
to be programmed.

So what can you do if you have the hardware, no specs and want to help ?

I will consider a case of a card where at least a basic driver exists and
you know the location and size of register aperture.

     * Study register header
         + note the size of register aperture
         + note register names - if any abbreviations are unfamiliar
           ask on the list. Perhaps, with time, a glossary can be made.

     * Study existing code
         + note any comments about the order of programming registers
         + note any code patterns that suggest that hardware needs
           to be in a certain state (like FIFO empty) before messing
           with some registers.

           Often these are encapsulated in the different OUTxxx or INxxx
           instructions.
         + note auxiliary address spaces. For example, PLL registers might
           need to be accessed by writing an address into a certain
           register and reading and writing a different one.

           Look out for
                 o PLL registers
                 o I2C busses - there could be more than one (very likely)
                 o VIP bus - could be more than one - a special purpose
                   high-speed parallel bus

     * As an exercise write a register scanner for Linux - this is
       a tool that uses /dev/mem (and, perhaps, /dev/iomem) to read
       values from all registers and print them.

          + You might need to write to a certain registers in order to
            access auxiliary address spaces

          + This tool is very useful to verify that the values are
            what the driver thinks they are.

                 o It could be that certain code is not called, but should

                 o It could be that special measures need to be taken
                   to insure that the values are actually written to
                   hardware - and don't stay in CPU cache for example

                 o The driver could be wrong. The register aperture
                   address could be wrong.

       You can use http://volodya-project.sf.net/hw_script.php for this.

     * Port it to Windows. You can use hws_win from
       http://gatos.sf.net/apps.php for direct access to memory mapped
       hardware (this is windows port of hw_script - though PCI id
       scanning is not supported yet).

     * If there is a particular feature that misbehaves - for example
       a new card fails to set mode correctly, but an older similar card
       works fine - try comparing register values to find out what is
       wrong.

Keep in mind that Windows drivers are usually written in close
collaboration with engineers that designed the hardware. The register
specs that are provided to public can be written days or weeks later -
and, sometimes, without contact with hardware developers.

Also, it could be that Windows driver accesses hardware only in a
particular way - and hardware was tested only for this access method.

Lastly, production hardware often has quirks that were not dealt with
because there is software workaround. These workarounds are sure to be
present in Windows drivers, but may not find their way to documentation.

After you worked with hardware and, perhaps, fixed a feature or two you
are in much better position to ask for register specs.

     * Companies are more likely to provide information about a particular
       feature or part of the chip - a lot less effort to make PDFs if
       they do not exist yet.

     * Companies are likely to be more friendly towards a developer that
       helped support their products.


                      best

                         Vladimir Dergachev