Re: PCI coprocessors
From: Andre Bonin (kernel_at_bonin.ca)
Date: 09/15/04
- Previous message: Benjamin Herrenschmidt: "Re: keylargo PCI USB controller nor enabled on G4 xserve"
- In reply to: Tomasz Rola: "Re: PCI coprocessors"
- Next in thread: Tonnerre: "Re: PCI coprocessors"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 15 Sep 2004 11:15:07 -0400 To: Tomasz Rola <rtomek@cis.com.pl>
Thank you for all your input on this. Of course i could do many things
on the board. The idea of the library is that a programmer would create
the fpga image file by him/herself and then put it in the library. The
kernel driver and the library does the decision if its worth putting on
the chip or not (that's optional, you could force it on chip).
Tomasz Rola wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>>Which leads me to my questions:
>>
>>1) Is their support for having two different 'machine types' within one
>>kernel? that is for example, certain executables for intel would get run
>>on an intel processor, and others would get run on processor with type XXXX.
>>
>>
>
>There are probably no impossible things - some may be unthinkable but once
>they are thought of, they can be done too. But this one thing may be
>rather difficult (just my opinion).
>
>
Yes i think so too, especially since it will be my first kernel module
(and anxiously waiting the next release of the o'reilly book for
refference).
>How about porting kernel and gcc to your fp-cpu and use pci as a
>kind of fast network-like interconnect? After loading a kernel into it
>somehow, boot it with nfs root and run the rest from nfs server that would
>be provided by a host Intel machine.
>
>
System-on-chips have been done before, and could be integrated into the
kernel like you said. But RAM becomes a problem. Since its only a
student project, we have a limit on the adressing width for the ram
(32bit addressing becomes 32 wires, that's a lot of wirewraping :) ).
>That would require less changes to a kernel, probably. A module for a
>host, for example - some "pci-net". And port of a kernel to your fp-cpu
>which should be easier than putting support for heterogenous
>multiprocessors...
>
>
I agree but i think that goes beyond the scope of the project. Though i
will consider it. Thanks for your input!
>- --
>** A C programmer asked whether computer had Buddha's nature. **
>** As the answer, master did "rm -rif" on the programmer's home **
>** directory. And then the C programmer became enlightened... **
>** **
>** Tomasz Rola mailto:tomasz_rola@bigfoot.com **
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGPfreeware 5.0i for non-commercial use
>Charset: noconv
>
>iQA/AwUBQUhX/xETUsyL9vbiEQKAlACg9Rv6rD8INCQFItk1/s5OfZbXjukAn2Mp
>PGjv6ihFXwTInSn8nu3ZOKpu
>=E5XU
>-----END PGP SIGNATURE-----
>
>
>
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Benjamin Herrenschmidt: "Re: keylargo PCI USB controller nor enabled on G4 xserve"
- In reply to: Tomasz Rola: "Re: PCI coprocessors"
- Next in thread: Tonnerre: "Re: PCI coprocessors"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
