Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Programming Hardware IT Technology

Obtaining VIA Datasheets? 32

driv3l asks: "This is totally frustrating! I'm trying to write some drivers for my Epia M10000 with a CLE266 chipset (VT8235 southbridge and VT8623 northbridge). The problem is that I can't get datasheets or info on any of the Via chipsets. I have a driver that works on my Intel ICH4 (knock Intel as much as you want... at least they're forthcoming with their technology). The Via datasheets request page does not work, and from what I've heard it's damn near impossible to get datasheets from them. I dislike looking through other people's source code, so looking through Linux drivers is counterproductive for me, especially since the driver I'm developing is not for Linux...or Windows, for that matter. This project is on its last legs due to the frustration I have been experiencing. Does anyone have any suggestions on how I can solve this problem or how I can go about obtaining the necessary datasheets?"
This discussion has been archived. No new comments can be posted.

Obtaining VIA Datasheets?

Comments Filter:
  • Try calling them?
    If you want it really bad (like it seems you do), try being social. It really doesn't hurt to talk to people every once in a while.
    • You have looked at their contact numbers right? No technical contact numbers, the only numbers they show are sales and PR (and I'm sure they'd have the faintest clue what datasheets are...) viaarena, the "technical support" site is virtually useless and has no contact numbers.
      • Call the sales number. Almost all tech sales people know what a datahseet is and how to get them. They may not be able to decipher them, but they know how to get them.
    • Well, the thing is damn near every chip manufacturer releases datasheets on their chips. That includes the obvious ones like Intel, Motorola, IBM, Texas Instruments, Fairchild Semiconductor, Microchip, Samsung, Micron, etc... and those are just off the top of my head. I used to have several 3" binders full of datasheeets printed 8 pages per sheet (4 pages front, 4 pages back) per project from other companies whose products we used in our designs. These datasheets were our bibles for the design. For VIA
    • I did look for phone numbers... and the only numbers available are marketing and sales.
  • "from what I've heard it's damn near impossible to get datasheets from them"

    Have you asked them yet ?

    A quick search reveals mailing lists where VIA engineers freely handed out technical data sheets for earlier models.
  • "I dislike looking through other people's source code, so looking through Linux drivers is counterproductive for me"

    I fail to see the link that the "so" implies.

    Just because you dislike reading other's code, doesn't mean it is counterproductive.
    • So if he wants to release his project under anything but the GPL, he better claim to not look at the Linux source. Or is having RMS on your back productive ;-)
      • Remember that you still have the standard Fair Use rights [] allowed by your jurisdiction. These will probably allow you to study and write your own code based on GPLed code, as long as you don't include actual GPLed code.


      • a) Your logic is screwed up. Saying that one doesn't like to read others code can not be concluded to that it would be counterproductive.

        b) He can look at the code all he wants, and use it to work out how the device works, and then write his own driver.

        Just looking at GPL code doesn't mean you can't then write your own proprietry code. What you can't do is just copy and paste the code.
      • You can take a GPL'd project, display the code in one window, and type in your own code, using it as the example, in another window, and as long as it is a different work, you have full copyright to the separate, non-derived work you just wrote. One way to try to make sure everything is different is to translate it into a completely different language. The important thing is to make sure you are not creating what would be a "derived work" under Title 17. An automated translation by a program would probab
    • Actually.... what I was trying to convey is that it is much easier and cleaner to work from a datasheet than trying to understand someone elses code.

      Maybe it's just me, but I find the linux code fairly complex to read and follow.

      It gets more hairy when trying to understand the interactions of the code with certains bits of hardware.

      By the time you've finished plugging in the constant values (#defines) and looking through the 10 different source files, you could have written 4 drivers.

      Also... working fro
  • Letters. (Score:2, Insightful)

    by Anonymous Coward
    Write a friendly e-mail to the webmaster, copied to the customer service department of Via, explaining the non-functioning link, and how much this would help you in supporting their product in another OS.

    Then, looking at their who's who corporate page find the closest things to their technical department, and customer service department. If they take longer than a week to respond to your e-mail with something that isn't computer generated, write a letter.

    The first paragraph should be high, how ya doing,
    • No, it's not worth it.

      There are other vendors, other products,
      and much much better ways of doing business
      and treating your customers.

      Instead, I suggest telling everyone in the
      industry how VIA is hostile to its customers
      and refuses to provide technical documentation
      for its products, rendering them useless.

      When you do a design, turn to a competitor.
      VIA's intransigence can be resolved by
      destroying VIA as an agent in the marketplace.

      Only the good survive. Helping this lawyer-crippled company to survive
  • VIA sucks for the GCC folks too. You'd think that a CPU manufacturer with a dramatically new design would at least sponsor someone on the GCC team to write an optimized C3 target. Instead we had to use i486+3DNow!

    Now with the nehemiahahaha CPU I think the -march=c3-2 target just points to i686+sse.

    If they kicked a few spec sheets and a small donation to the GCC folks I'd bet GCC-generated code would run 30% faster on their chips. The C3 series should have it's own pipeline description and scheduling backe
    • Yeah, I really wanted to take a look at what kind of stuff they had for the M10000's often-touted CPU crypto features. But I was very disappointed when I found absolutely no technical documentation on those things whatsoever. Nothing beyond marketing hype. What a gyp.
  • There are numerous "fan-sites" about mini-ITX boards, especially those from VIA. Maybe some of the folks on there have already managed to obtain some docs.

    For example: [] have sections about linux and mini-itx boards.

    Or how about the kernel mailing lists? I think that Alan Cox himself mentioned in his diary (before he started writing it in Welsh, that is) that he's a fan of these machines and had done some driver development.

  • by Anonymous Coward
    someone [e.g. avnet?] will be a representative for them, and someone will be the distributor.
    these are the normal channels to deal with a semiconductor mfg.
    the rep will be able to provide the datasheets etc (perhaps under NDA, depends on company).
    • I certainly wouldn't waste any time dealing with a distributor or field rep. They rarely have an adequate understanding of the language even if they speak english as a 1st language, won't relay the message till next tuesdays weekly confab, and it will get routed first to the legal dept. for a 30 day review, then get bounced back to sales, who A: won't know by then what was asked and B: will call you and ask you how many units you're talking about. You'll explain that its data sheets you want and then the
  • You might want to check with the developers of LinuxBIOS []. I know that they have had some luck working with VIA. There knowldge should be sufficiently low-level for you to be able to write drivers.

Nothing makes a person more productive than the last minute.