Charlas 13-12-2000 Umeet'2000

Charlas 13/12/2000

Log de la conferencia. Se han suprimido las líneas correspondientes a entradas y salidas de diferentes personas en el canal durante la conferencia
Philipp Rumpf "Linux on Undocumented Hardware"
[22:17] (fernando> Hello,
[22:17] (fernando> we are very please to have here Philipp Rumpf
[22:18] (fernando> He lives in Erlangen and he is currently studying mathematics at the
[22:18] (fernando> University of Erlangen-Nurnberg
[22:18] (fernando> He's worked on the Linux Kernel for a while, and he claims he's played
[22:18] (fernando> with about every subsystem it has
[22:18] (fernando> He is not currently employed by any Linux company.
[22:18] (fernando> volunteers??? :)
[22:18] (prumpf> I'm very pleased to be here :)
[22:18] (fernando> His talk will be about:
[22:18] (fernando> Linux on Undocumented Hardware
[22:18] (fernando> Thank you to our speaker and to all of you for comming here.
[22:18] (fernando> Philipp....
[22:18] (prumpf> okay
[22:18] (prumpf> let's start by clarifying that title a bit
[22:19] (prumpf> when I say "undocumented hardware", I don't mean ancient macs, and I don't mean pdp-11s
[22:19] (prumpf> I mean those devices most of us probably have seen a lot this past year
[22:19] (prumpf> handheld or laptop devices running Windows CE
[22:19] (prumpf> the reason for this is that I think that Windows CE runs on most of the interesting undocumented hardware nowadays
[22:20] (prumpf> all hardware running Windows CE, as far as I'm aware, has a MMU, which allows you to run a "real" operating system and get multitasking, memory protection .. and it makes running standard Linux/Unix software possible
[22:20] (prumpf> most Windows CE devices have a lot of RAM, at least compared to calculators and cell phones
[22:20] (prumpf> usually the OS itself is stored on ROM or flash rom
[22:20] (prumpf> of course, it's a natural idea to run Linux on those
[22:20] (prumpf> there's hack value: running Linux on any system that wasn't originally intended for it sounds tempting to most hackers
[22:21] (prumpf> and trust me, it's actually great when you did it and this device you have only seen running Windows so far sits there at a bash prompt :)
[22:21] (prumpf> there are more mature reasons as well
[22:21] (prumpf> for certain applications, Linux simply is the better operating sysetm
[22:22] (prumpf> Windows CE doesn't have anywhere close to as many applications as Linux
[22:22] (prumpf> and, of course, Windows CE isn't free. It's not free of charge, and it's not F
[22:22] (prumpf> and, of course, Windows CE isn't free. It's not free of charge, and it's not Free in the Free Software sense
[22:23] (prumpf> so that's basically my motivation for porting Linux to devices currently running Windows CE
[22:23] (prumpf> if you have any questions or comments during the talk, there is a #qc channel which i'll be trying to monitor
[22:24] (prumpf> of course, some of the Windows CE devices are documented, and most of the documented devices have Linux ports already
[22:24] (prumpf> the specific device I was porting Linux to is the Compaq Aero 8000, which is a small laptop running Windows CE or, for a few weeks now, Linux
[22:25] (prumpf> many people tell me there's still plenty of undocumented hardware left for YOU to port Linux to, and I hope this talk might help with that a bit
[22:26] (prumpf> so, how do you go about porting Linux to such a device ?
[22:26] (prumpf> First, you need to run some sort of boot loader or gdb stub on the device
[22:26] (prumpf> this requires you, obviously, to actually run code on it; this isn't a problem with most operating systems, which can load binary executables in mostly standardized formats.
[22:27] (prumpf> such as ELF or COFF, or even PE, which is what Windows CE uses
[22:27] (prumpf> Some devices don't run a real operating system though (like cell phones and calculators), and some use a binary format that isn't known, or not supported by GNU binutils (in particular, Windows CE uses the PE format, which isn't completely supported by GNU binutils).
[22:28] (prumpf> this means that we don't really want to go to the hassle of fixing GNU binutils and GCC so we can compile Windows CE applications with it
[22:28] (prumpf> we want to get rid of Windows CE, not add to it
[22:28] (prumpf> What works well for these devices is taking an existing executable (or part of the ROM, whatever), finding a (reasonably long) piece of code that gets run early, and replacing it with your code. This requires some disassembly, which I'll cover later.
[22:29] (prumpf> of course you can compile your C code with Microsoft's compiler as well
[22:29] (prumpf> but that requires you to run windows and use non-free tools
[22:30] (prumpf> you can simply take any windows ce binary (preferrably one without a copyright), and put your assembled code into it, replacing the windows ce code.
[22:30] (prumpf> so this will have us running any code we want under Windows CE, or other operating systems
[22:31] (prumpf> but usually user code isn't run with the CPU in privileged mode, so you'll have to find another way to access privileged resources, such as IO space and all of your RAM
[22:31] (prumpf> Some versions of Windows CE seem to always run the CPU in privileged mode, and others provide a SetKMode() syscall which switches the CPU into privileged mode
[22:31] (prumpf> This has the additional advantage that you can disable interrupts, which effectively means the original operating system can't get control of the CPU back from you by servicing interrupts - in other words, you're free to reuse its memory
[22:32] (prumpf> Doing the equivalent thing for Unix-like operating systems is a lot harder, since they don't usually allow anyone to put the CPU into privileged mode
[22:33] (prumpf> instead, you'd have to use /dev/mem and patch the kernel
[22:33] (prumpf> so now we have a piece of code running in privileged mode, we want to load a kernel image, or a gdb stub
[22:34] (prumpf> Loading a kernel image can be done either using the native filesystem or directly accessing IO devices;
[22:34] (prumpf> the native filesystem approach requires you to be a lot more careful about what you do, since any point in the loading process you need to be able to run part of the native os or other tasks, which won't work if you've already scribbled over their memory. It also requires you to have your code do syscalls, which might be very hard or completely impossible when you don't know the binary format in question.
[22:35] (prumpf> of course this approach is quite elegant, since you don't need to know about any hardware
[22:35] (prumpf> but since you need to know about the hardware anyway, since you're going to run Linux on it, I dont 'think that's a good argument
[22:36] (prumpf> The direct IO access approach requires some knowledge about the hardware you want to access, which means that in the worst case, you'll have to guess about things while you can execute assembler code only (since C code requires a relatively large runtime and working compiler support).
[22:36] (prumpf> I think the direct IO access approach wins, since it minimizes the amount of code that tries to co-operate with the existing operating system rather than replace it.
[22:37] (prumpf> htis means your code will be more easily portable to similar devices
[22:37] (prumpf> Another decision is whether you want to use a gdb stub or a "real" boot loader; since this doesn't depend on whether the hardware is undocumented, I won't spend a lot of time on it
[22:38] (prumpf> but when you need to inspect IO registers and memory, a gdb stub is extremely convenient.
[22:38] (prumpf> so, at this point we have a boot loader, and we've gone through the boring decisions
[22:39] (prumpf> you will notice that I actually did assume we know a bit about the hardware here - enough to use one serial port
[22:39] (prumpf> my impression is this is true for most systems, but I will talk about the case where it isn't some more in the third part of the talk
[22:40] (prumpf> the second part of the talk will cover reverse-engineering, and making educated guesses about hardware
[22:40] (prumpf> but before I start with that, I think this might be a good point to ask questions about the talk so far
[22:42] (prumpf> to summarize, I have covered the two basic types of boot loader, and I hope I've made a point for using a gdb stub rather than a full-blown boot loader
[22:42] (prumpf> With a gdb stub, or a complete boot loader, we're able to boot a kernel already
[22:43] (prumpf> this kernel only can support a serial port, but it will already run and should give us more information about the CPU and the possibility to access the IO address space and the ROM
[22:43] (prumpf> This is a very important point in the porting process, and one which you should duly celebrate ;).
[22:44] (prumpf> the next part of this talk will be about hardware rather than software: it's basically about adding drivers to the very small kernel we're running now so it will support a real Linux system.
[22:44] (prumpf> Of course you will try to avoid writing those drivers if at all possible - using someone else's code saves most of the effort on your part, and many drivers support different chips already, so adding yours might be as simple as putting two or three #defines in a header file in include/asm.
[22:45] (prumpf> First, let's have a look at how many embedded system (and quite a few non-embedded systems as well) actually look like IO-wise:
[22:45] (prumpf> usually, we have only two or three chips that are directly accessible (the CPU, a SuperIO chip which has a variety of functions, and possibly an LCD controller).
[22:45] (prumpf> It's extremely convenient to have some way to interactively do I/O accesses, and I'll assume we have one in the rest of this discussion. Maybe I should point out again that an easy way to do this is running a gdb stub on the target directly, without an operating system underneath it.
[22:46] (prumpf> When I'm referring to an "I/O dump" lateron, what I mean is reading every address in a long range and printing the value read - while this might be destructive to device state and isn't a good idea while the system is running, it usually doesn't confuse devices so much the system has to be rebooted to be usable again.
[22:46] (prumpf> so, what you are doing now, in your porting project, is to try reading different IO addresses
[22:47] (prumpf> and see whether you can find any devices, that is any IO addresses that read with interesting values rather than all-zeroes/all-noes
[22:48] (prumpf> Most current CPUs have very large address ranges for I/O accesses, so finding any device at all might require simple scannning code to avoid having to read thousands of screens of all-zeroes / all-ones IO dumps - but since there are only a few chips, and usually there is only one IO range used by each chip, you'll usually only find large blocks of interesting IO addresses
[22:49] (prumpf> There are two important hings to consider when trying to find out which I/O ranges actually access interesting devices:
[22:49] (prumpf> first, some address lines might not be decoded
[22:50] (prumpf> so the same register values will repeat over and over again, and both the size of the repeated region and the number of repetitions will be a power of two
[22:51] (prumpf> this means there will be regions in our IO dumps that we don't want to consider, since they're just aliases of a region that already occured earlier
[22:51] (prumpf> detecting those aliases is very easy when you can write to a register - if it changes in both regions, they're aliases, otherwise, you're dealing with two devices that just happen to look similar
[22:52] (prumpf> it is generally a good idea to use the lowest address that will access a device, rather than any higher alas
[22:52] (prumpf> so, this is relatively easy to deal with.
[22:53] (prumpf> the second important thing is that some devices stop responding to read accesses when they're suspended for power management
[22:53] (prumpf> those devices need special write sequences to re-enable them. Those sequences are usually very hard to guess and can't be tested without potentially corrupting hardware state; on the other hand, reverse-engineering them from the bootup or driver code might be extremely easy.
[22:54] (prumpf> if you have a superio chip, it is commonly the case that the registers that disable certain functions are in one contiguous region
[22:55] (prumpf> so you can be relatively sure you've found all devices when you manage to find this region and enable all functions in it, then dump the IO space
[22:55] (prumpf> afterwards you can delete all aliases and end up with a smaller dump, which you can try associating with devices
[22:56] (prumpf> there are some easily recognizable patterns that occur for certain devices for which there are widely-accepted standard register layouts
[22:56] (prumpf> the most obvious example are serial ports, which use the 16550 layout
[22:57] (prumpf> Another easily detectable piece of hardware is a framebuffer -- usually a large bloc of readable and writable memory, with writes having very visible effects.
[22:58] (prumpf> there are standard register layouts for many other functions, such as USB and I2C
[22:58] (prumpf> interrupt controllers/multiplexers aren't standardized, but the most common kind seems to have three registers: one which indicates which interrupts
[22:59] (prumpf> are pending, one indicating a mask of ignored interrupts, and the third containing the logic AND of the first two registers - the idea is that only the third register needs to be read in the interrupt demultiplexing routine.
[23:00] (prumpf> so usually we can determine a lot of the devices we have just by looking at the IO dump and finding likely candidates, then testing whether they are really the devices we're looking for by doing write accesses
[23:01] (prumpf> basically, this was the part about making educated guesses about our hardware, based on the register values we read
[23:01] (prumpf> but usually that isn't enough, and we'll have to look at the drivers the native OS (i.e. Windows CE, in our example) is using
[23:02] (prumpf> that is, we need to reverse-engineer them
[23:02] (prumpf> WARNING: reverse-engineering is a difficult legal subject, and laws vary wildly between the EU and the US, with most other countries being somewhere in between. I can't give legal advise on this. I also want to make it clear that this information isn't intended to be used for illegal reverse-engineering. Check your copyright and trade secret laws.
[23:03] (prumpf> It is easy to get a ROM dump once you're running Linux: since the ROM is usually mapped directly into the CPU's address space, /dev/mem can be used to read it. If you're lucky, the ROM isn't compressed, so finding the driver you're looking for might be as easy as searching for obvious strings in your favourite hex editor - keep in mind Microsoft operating system commonly use 16-bit Unicode characters for strings.
[23:04] (prumpf> you can also try to find out how the Windows CE ROM filesystem, or whichever filesystem your OS is using, works, but that seems to be rather difficult and looking for strings gives satisfactory results
[23:04] (prumpf> Once you have extracted a driver out of the ROM dump, it is very easy to disassemble it, even when GNU binutils don't support the object format used:
[23:04] (prumpf> (target>-objdump -D -m(architecture> -bbinary dump.bin > dump.txt
[23:05] (prumpf> should give you a reasonable result, though you need to worry about endianness
[23:05] (prumpf> as well.
[23:05] (prumpf> Actually making sense of the disassembler output is harder, and usually you want to avoid reading and understanding large sections of code - not only does it take a long time,
[23:05] (prumpf> but it might be creating additional legal problems, especially when you have to reimplement relatively complex algorithms you've read the disassembled source for.
[23:06] (prumpf> When all you're looking for is the base address for some hardware, or some hints that might allow you to find the right register layout for it, searching the binary for word-sized constants or strings might help you a lot without too much effort -- and possibly with fewer legal problems than for a full disassembly.
[23:08] (prumpf> you notice I'm being a bit verbose on "legal problems"; that's because there seems to be an insane number of lawsuits about reverse-engineering, and you don't want to make yourself a target for thme.
[23:08] (prumpf> Very commonly reading the routines that directly access I/O space gives you all the information you need to write a working driver for the device, and it usually doesn't take too long (though finding out which routines access I/O space isn't entirely simple in the case of remapped I/O ranges).
[23:08] (prumpf> so, again, we can avoid reading the whole driver, or even large parts of the drive
[23:09] (prumpf> we look for IO addresses, try to find out how they're used from context, then end up with a number of routines we can simply test the effects ofM
[23:10] (prumpf> a full disassembly almost certainly takes more time than you're willing to spend on one device, and you don't get anything for most of the time you spend on it, either
[23:10] (prumpf> Error message strings are the closest you have to comments in disassembled code, so reading them carefully and matching them up with code can help a lot.
[23:10] (prumpf> when you have the choice between reading English text and reading disasembled source, English wins
[23:11] (prumpf> If you indeed decide to do a more complete disassembly, you will find that you're trying to match up virtual addresses used in the disassembled source with the addresses objdump used for the disassembled source - by default, it starts at address 0. The --adjust-vma option might work for this, or you might have to split up the binary dump at page boundaries.
[23:11] (prumpf> this, again, is something only to do when you find out you need it
[23:13] (prumpf> the less time you spend looking at disassembled source, and the sooner you make sure you've deleted all copies of the rom, the less legal problems you might have to deal with
[23:13] (prumpf> So much for disassembling once you have a rom dump and a running linux system or a gdb stub.
[23:14] (prumpf> This is a lucky situation: you already know about one serial port at least
[23:14] (prumpf> but sometimes you aren't ugly, and you can't even get a gdb stub running without additional information.
[23:14] (prumpf> This means that the only device you could find is the framebuffer, or not even that.
[23:15] (prumpf> Since the framebuffer isn't a very good output device (unless you _like_ to write down 16 MB of hex numbers), this means all you have is an indication your program is running at all, and maybe some debug information.
[23:15] (prumpf> but it's not enough to disassemble code, because you have to copy it down from the display byte-for-byte
[23:16] (prumpf> obviously, this is a very bad situation, and for a long time I didn't think I could find a solution
[23:16] (prumpf> but there is one
[23:16] (prumpf> on operating systems that keep their read-writable filesystem in RAM (Windows CE does this on most devices), and on operating systems that cache file data in RAM, you can still get a copy of the ROM, even without knowing about the serial port
[23:17] (prumpf> the idea is that we can overwrite a file's data in physical RAM, without the native OS knowing we did so
[23:18] (prumpf> if we create a file containing magic numbers, we can search for these magic numbers in our Windows CE program and replace them with parts of the ROM data
[23:18] (prumpf> then we can copy the file back to a linux box and disassemble it like we would a rom dump created from within Linux
[23:19] (prumpf> the important point here is we don't know anything about the serial port, framebuffer, or keyboard/touch screen
[23:20] (prumpf> you still have to make sure the file you want to modify doesn't contain any data that compresses well, since Windows CE, and other operating systems, transparently compress data when possible
[23:22] (prumpf> I got the impression that many people are stuck in a position where this hack would help them
[23:24] (prumpf> at the end of this talk, I'd like to mention some projects that I think would help Linux port to more Windows CE devices, but which I won't be able to work on anytime soon
[23:24] (prumpf> 1. Support for Windows CE's ROM filesystem in Linux, either as a kernel space filesystem or as a set of userspace utilities
[23:25] (prumpf> 2. Better support for the PE format in GNU binutils
[23:26] (prumpf> 3. A smarter disassembler than objdump, which still works for a wide range of architectures and keeps up-to-date with GNU binutils changes
[23:26] (prumpf> 4. The ability to run Windows CE binaries in Linux
[23:28] (prumpf> I think it's obvious 4) requires 1) and partially 2), but we should try to nullify all arguments against running Linux on Windows CE hardware.
[23:28] (prumpf> are there any questions ?
[23:28] (MJesus> clap clap clap clap clap clap clap clap clap clap
[23:28] (MJesus> clap clap clap clap clap clap clap clap clap clap
[23:28] (MJesus> clap clap clap clap clap clap clap clap clap clap
[23:29] (MJesus> clap clap clap clap clap clap clap clap clap clap
[23:29] (MJesus> clap clap clap clap clap clap clap clap clap clap
[23:29] (fernando> plas plas plas plas plas plas plas plas plas plas plas plas
[23:29] (fernando> plas plas plas plas plas plas plas plas plas plas plas plas
[23:29] (fernando> plas plas plas plas plas plas plas plas plas plas plas plas
[23:29] (mje> clap clap clap clap clap clap clap clap clap clap
[23:29] (mje> clap clap clap clap clap clap clap clap clap clap
[23:29] (mje> clap clap clap clap clap clap clap clap clap clap
[23:29] (mje> clap clap clap clap clap clap clap clap clap clap
[23:29] (mje> clap clap clap clap clap clap clap clap clap clap
[23:30] (fernando> well, let's start with questions ....
[23:30] (Kerberos> plas plas plas plas plas plas plas
[23:30] (Kerberos> plas plas plas plas plas plas plas
[23:31] (prumpf> there was one question that was asked very early during the talk, which was how this applies to systems that don't run Windows CE
[23:32] (fernando> yes
[23:32] (fernando> do you have experiences with other OS's ?
[23:32] (prumpf> I think most of it can be applied perfectly well, but there are important differences between Windows CE and other operating systems
[23:33] (prumpf> some operating systems make it even easier to read system files and access privileged resources
[23:34] (prumpf> DOS would be a typical example :)
[23:34] (prumpf> (but Amigas and Acorns ran operating systems which preserved these attributes as well)
[23:35] (prumpf> some other operating systems make it very very hard to access the hardware from userspace or to modify the kernel; those are mostly Unix variants
[23:37] (trusmis> do you think that a person that hardly has read some kernel codes but has a not-bad hardware knowledge is able to do something interesting ?
[23:38] (prumpf> which means that they use a real boot loader anyway, so you don't need to do any of the hacks required to load one OS from anotehr
[23:38] (prumpf> so, to summarize, I don't think there are many operating systems out there which make porting harder than Windows CE
[23:38] (prumpf> even game consoles usually allow you to access the hardware directly and sometimes document their hardware
[23:38] (prumpf> does that answer the question ?
[23:38] (prumpf> yes, definitely.
[23:39] (trusmis> i don't catch very well that part of the magic numbers and replacing for rom -code
[23:40] (trusmis> it really work?
[23:42] (prumpf> the question was i don't catch very well that part of the magic numbers and replacing for rom -code it really work?
[23:43] (prumpf> it works, since Windows CE doesn't checksum its file data
[23:43] (trusmis> ohh , then not wrong .exe ......
[23:43] (prumpf> the blocks of the file are scattered all over the device's physical memory
[23:44] (prumpf> we find them and overwrite their contents, but we do this, of course, out of order
[23:46] (MJesus> what would be the main difference between running Windows CE binaries in Linux and running Windows XXX binaries in linux ?
[23:48] (MJesus> lagggggggg!!
[23:51] (prumpf> I have to admit I wasn't entirely serious when I asked for Windows CE binary support in Linux
[23:52] (prumpf> but I am completely serious when I ask for Windows CE _source_ support for Linux
[23:52] (prumpf> running programs written for Windows CE is the easiest way to ensure Linux on those devices will become at least as useful as Windows CE.
[23:53] (prumpf> does that answer that question ?
[23:53] (MJesus> ja!! thanks !
[23:55] (prumpf> any other questions ? the ones so far were extremely interesting
[23:55] (MJesus> yes!
[23:56] (CtrInt> may I break my hardware doing nasty things on porting?
[23:56] (prumpf> very good question.
[23:56] (CtrInt> as i done with some pc devices.. :-P
[23:56] (prumpf> I've been worried about that myself
[23:57] (prumpf> so far I know about two things that might make your hardware unusable:
[23:57] (prumpf> 1. writing to a flash rom too often, or writing bad data to it so it won't boot anymore.
[23:57] (prumpf> 2. disabling/enabling an lcd display very often and without the proper power-off/power-on sequences
[23:59] (prumpf> I suspect some low-end devices have a battery charging unit that's controllde by software and can break the battery, but I haven't heard confirmation for that.
[23:59] (prumpf> so I'd say that there is a risk but it is very low.
[0:00] (CtrInt> I understand breaking the boot on flash by bad code on it but... can be broken by writing frecuencly to it?
[0:01] (prumpf> flash rom only supports a limited number of write/erase cycles, typically 100,000 to 1,000,000
[0:03] (fernando> so...
[0:03] (fernando> more questions?
[0:03] (prumpf> (or comments, of course)
[0:04] (^J0eL_R^> cuando comienzan las conferencias?
[0:04] (trusmis> prumpf: do you think linux will beat CE in short term¿?
[0:04] (trusmis> i have seen lots of windows ce nowadays :(
[0:05] (prumpf> trusmis: I think both Linux and Windows CE will become, absolutely, more popular in the short term for small-scale pc-like devices
[0:07] (fernando> I think is time to thank to our speaker and to all of you for comming here
[0:07] (fernando> feel free to continue discussing about the topic
[0:07] (prumpf> trusmis: so the important thing is that we can make those devices run Linux well and usefully, and then hardware manufacturers will start using Linux more frequently, and then it's up to the market to decide
[0:07] (prumpf> fernando: thanks for making this possible for me
[0:07] (fernando> the recording of this talk will be on the web as soon as possible (typically in 8-9 hours, when our webmaster will wake up)
[0:08] (trusmis> the weell if linux work -> people use -> manufactures realizes -> linux work
[0:09] (fernando> joel today it is finishing
[0:09] (fernando> next talk will be tomorrow
[0:10] (MJesus> clap clap clap clap clap clap clap clap clap clap
[0:10] (MJesus> clap clap clap clap clap clap clap clap clap clap
[0:10] (MJesus> clap clap clap clap clap clap clap clap clap clap
[0:10] (MJesus> clap clap clap clap clap clap clap clap clap clap
[0:12] (prumpf> trusmis: there's a very important first step to do here, which is to make Linux work on as wide a rage of hardware as possible
[0:12] * trusmis agrees
[0:13] (trusmis> to make linux work _well_
[0:15] (fernando> see you tomorrow
[0:15] (trusmis> do you think in the future most drivers will be Gpl?
[0:16] (trusmis> i'm thinking in nvidia and others that seems to not free them
[0:16] (prumpf> there are high-end devices, and I'm not sure how much co-operation to expect from those manufacturers
[0:17] (prumpf> for mid-range devices, not supporting linux would mean losing a significant part of the market share, and soon nvidia will realize that
[0:17] (prumpf> for low-end / embedded devices, cost is of paramount importance
[0:18] (prumpf> those hardware manufacturers have little to lose by giving out their driver source code, and some (like Epson) have been doing that.
[0:20] (Ricardo> They win much more than lose
[0:21] (trusmis> what will be the first steps to get info if for example i have a sound card and no doc about it ? and even no windows driver, any way to achieve information?
[0:21] * trusmis wasn't here all the talk , sorry if you say it before
[0:25] (prumpf> trusmis: of course there's the chance that the hardware is sound blaster compatible
[0:25] (trusmis> if not
[0:25] (trusmis> ?
[0:26] (prumpf> trusmis: but there is no real standard for sound cards, so you might need to disassemble the driver or look for other ways to find things out
[0:26] (prumpf> of course, the _first_ step is to ask for documentation
[0:27] (Ricardo> prumpf: who knows? They sometimes even give you the doc X)
[0:27] (prumpf> ricardo: indeed.
[0:27] (trusmis> prumpf: they use to give you something?
[0:27] (prumpf> trusmis: some vendors give out documentation to linux developers, yes.
[0:28] (trusmis> prumpf: interesting, .....
[0:32] (trusmis> prumpf: what do you recommend a beginner can begin with?
[0:32] (trusmis> prumpf: something easy ... that make you learn...
[0:33] (Ricardo> Uh
[0:33] (Ricardo> He told 'easy'
[0:33] (Ricardo> :D
[0:36] (prumpf> trusmis: for doing what ?
[0:37] (trusmis> a driver
[0:37] (calc> write a usb driver for the 3com usb camera :)
[0:37] (trusmis> i think all net card drivers are almost the same
[0:38] (trusmis> somethink like that, you can take a look at the already made code what make it easier
[0:39] (prumpf> sound drivers are interesting and easy, but you might not be able to use what you learn.
[0:39] (makross> byes, and thx :))
[0:47] * prumpf leaves
[0:47] (prumpf> thanks everyone
[0:47] (trusmis> thank you
[1:02] *** prumpf has quit IRC (Leaving)
Y seguimos un buen rato más charlando...

Contact: