Re: want to be a hardware developer ?

Vladimir Dergachev writes:
 > 
 > 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

Yes, and manufacturers are very inventive when it comes to register
names.

 > 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.

This can be a very frustrating experience.
One may find himself rebooting you box hundreds of times a day.
One should better be prepared for that.

 > 
 > 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.

The least common denominator with most cards is the VGA compatibility.
Even if one doesn't use the legacy register range, the VGA registers
are frequently mapped to MMIO.

 > 
 >      * 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.

Register names differ between vendors. This may not be too helpful.

[...]
 > 
 >      * 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.

This will not work on all platforms. ia32 and friends are quite save.
On AXP or ia64 one is likely to trigger a machine check.

 >      * 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).

Interesting idea. One may also 'reverse engineer' the Windows driver.
People have done so successfully. I cannot offer any tools to do
this though.
 
 > 
 > 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.

This is the usual case. Hardware is not going to be changed for
anything that can be fixed by a workaround. This will only
happen, if some advertised feature cannot be implemented.
Don't expect the 'bug' to go away with the next generation:
it may have become a 'feature'!
One would really needed errata sheets. However if those exist
at all they are even harder to get.

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

Egbert.