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
