Re: Learning hardware ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 19, 2010 at 3:16 PM, StephanT <stman937-linewbie@xxxxxxxxx> wrote:
>>
>
>> Any suggestions what can I read ?
>>
>
> Is your list ready ?        :o)
>
> 1. User Guide - Data Sheet
> 2. Application Notes
> 3. Code examples
>
> 4. Use Wikipedia to get quick answers and directions.
>
>
> I assume you have the basics (from what I already know about you).
> So, unless you have a very good recommendation don't spend money
> on books.
>
> Each manufacturer provides these docs on his WEB site. Download,
> scan-read and delete if not interesting. Keep otherwise. This is not
> pleasure neither casual reading. DO not try to read them like an History
> book or the last NYT bestseller. Learn to scan quickly. At the beginning
> you may get lots of questions. Clear them on Wiki and the NET. Use the
> Application Notes to "see" how others implement
>
> From my experience it is important to focus on one problem at a time.
> Go as deep as you can and when you sure you got it go to next topic.
> Do not try to read the UG from the first page to the last. Go straight to
> the chapter of interest. Say this is the UART. Start reading. They will
> mention the system clock - jump there get some insight come back
> and follow - and so on. If this really fires you fine - you are on your
> way to the knowledge. If not, go switch to Java :o)
>
> Actual micro-controllers, SOCs, CPUs are roughly the same - well from
> 30,000 feet above. You study the UART on one you'll have no problems
> to switch to another.
>
> This is it - don't look for some magic. And don't forget to use the Wiki,
> Luke, use the Wiki.
>
> Good luck,
> Stephan.
>
> ps. There are lots of Wikis. There is Mother Wiki but you will find
> more specialized. Search the net for Wiki.

I agree with the above approach.

I can typically now read a data sheet and know what it means, but if
you come across a phrase or concept you don't know, then you have to
look up what the words mean.

To get you started, here's the AHCI spec.  130 pages of pleasure reading!

http://download.intel.com/technology/serialata/pdf/rev1_3.pdf

Even if you're not interested in storage/sata, I recommend you take an
hour or so and scan that spec.  It's very well written and gives you a
good feel for what you as a software person should be interested in.
You will note that it spends very little time if any talking about
voltages, physical parameters, etc.  Instead it is predominantly
filled with information a hacker working on the AHCI linux driver
would need to know.

You can find some other nic and controller specs here:
http://gkernel.sourceforge.net/specs/

Alternatively, this list all links to the above docs, but is a little
easier to review for me:
http://www.linuxfoundation.org/collaborate/workgroups/networking/network-adapters#Hardware_specifications

But, when I think of "hardware", I also include the ATA, SCSI, and
Ethernet standards at a minimum and you may want to get a copy of the
PCI / AGP / PCIexpress etc. standards too.

Since I'm a storage guy, I'll hit the ATA and SCSI standards real quick:

The ATA-8 standard incorporates IDE drives, SATA drives, and the
latest and greatest SSD drives.  (You may have trouble finding a ATA-8
spec.  What you typically find are draft specs that are piecemeal.
Once a spec is finally accepted, it is my understanding you have to
pay for them.  So most of us work from the latest draft spec. which is
typically free, even if it's hard to find!)

The SCSI standard is actually more like a 7-layer network stack.  So
to my surprise several years ago I found out that USB drives actually
fit in the SCSI stack and SCSI commands are sent back and forth across
the USB bus.  Then at least for USB enclosures with rotating disks you
will typically find a SAT (SCSI to ATA Translator) inside.  It is used
at the end of the USB bus to map the commands to ATA for delivery to
the actual drive.

There is actually a SAT spec. out there somewhere if you really want to dive in.

So the SCSI standard(s) cover parallel SCSI, SAS, FC, iSCSI, and USB
at a minimum!

Clearly you need to decide if this kind of "hardware" interests you.

fyi: To get extremely detailed in the hardware side you will need some
test equipment, but don't let that scare you away.  As an example, for
SATA they make a bus analyzer that can monitor everything on the sata
bus and decode the commands for you.  If you're getting into the nitty
gritty of what's going on you may need one of these, but I don't get
the impression most linux kernel developers have this type of
equipment.  It's simply too expensive for the majority of people /
companies and you can do a lot of productive work without having one.

Greg

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux