Re: FPGA programming driver architecture
>> [various FPGA config methods] Don't forget JTAG, and playing back an SVF files, or BIT files. -Duane. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FPGA programming driver architecture
Hello, On Thu, Jan 8, 2009 at 11:57 PM, Florian Fainelli wrote: > Le Thursday 08 January 2009 23:47:58 Leon Woestenberg, vous avez écrit : >> The programming back end should be generic enough so that it can use >> other subsystems. >> > That's the idea behind using request_firmware, which provides you with both a > pointer to the data and the size of the blob. I know, that's what I would call the front-end (near userspace). I meant the low-level back-end (towards hardware): > - fpgaload-core which contains all the code that can be shared > between the drivers like requesting firmware, providing sysfs > attributes, > - fpgaload-spi would handle the low-level SPI connection > - fpgaload-par would handle the low-level parallel connection > > fpgaload-ser and par would register with fpgaload-core and they could > register a fpga loading callback which is low-level specific for > instance. My $0.02 was: Those callbacks should also be able to accept chunks of data (preferably in the same way using ptr/len). Regards, -- Leon -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FPGA programming driver architecture
Hello, Le Thursday 08 January 2009 23:47:58 Leon Woestenberg, vous avez écrit : > Indeed. > > The programming back end should be generic enough so that it can use > other subsystems. > > The FPGA configuration interface could be on the memory bus (and in > many cases the DMA helpers can be used) or behind a PCI bus, or can > even have SPI etc front-ends. > > In general the programming API should accept a blob of data, > preferably in one chunk (pointer plus length) or at least 4kB chunks > or so, so that configuration is not severy overheaded by a callback > per byte (or even bit). That's the idea behind using request_firmware, which provides you with both a pointer to the data and the size of the blob. -- Best regards, Florian Fainelli Email : flor...@openwrt.org http://openwrt.org --- signature.asc Description: This is a digitally signed message part.
Re: FPGA programming driver architecture
Hello, On Thu, Jan 8, 2009 at 11:14 PM, Thiago Galesi wrote: >> > > Hi, >> > > I have written some code to program a FPGA in Linux, for two >> > > different types of boards: one uses a serial interface (SPI) and >> > > the second a parallel interface. I have been able to sucessfully >> > > program both boards. I'm now trying to clean my code and make it >> > > more generic, as well as better in line with the Linux driver >> > > model. > > Considering the several FPGA models available and ways to program it, > I guess the important thing to consider is what can be made generic. Indeed. The programming back end should be generic enough so that it can use other subsystems. The FPGA configuration interface could be on the memory bus (and in many cases the DMA helpers can be used) or behind a PCI bus, or can even have SPI etc front-ends. In general the programming API should accept a blob of data, preferably in one chunk (pointer plus length) or at least 4kB chunks or so, so that configuration is not severy overheaded by a callback per byte (or even bit). Regards, -- Leon -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FPGA programming driver architecture
> > > Hi, > > > I have written some code to program a FPGA in Linux, for two > > > different types of boards: one uses a serial interface (SPI) and > > > the second a parallel interface. I have been able to sucessfully > > > program both boards. I'm now trying to clean my code and make it > > > more generic, as well as better in line with the Linux driver > > > model. Considering the several FPGA models available and ways to program it, I guess the important thing to consider is what can be made generic. (that is what will become fpgaload) Also, there may be cases where after FPGA is programmed it "becomes a device" (PCI or whatever) > > > > - fpgaload-core which contains all the code that can be shared > > between the drivers like requesting firmware, providing sysfs > > attributes, > > - fpgaload-spi would handle the low-level SPI connection > > - fpgaload-par would handle the low-level parallel connection I think this maybe split into three layers (maybe) 1 - low level connection: paralell / spi / i2c / whatever 2 - vendor: xylinx, altera, etc 3 - generic stuff Take a look at the MTD and SPI drivers and how they split things -- - Thiago Galesi -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FPGA programming driver architecture
On Sat, 13 Dec 2008 13:58:01 +0100 Florian Fainelli wrote: > (CC'ing linux-embedded) > > Salut Hugo, > > Le Friday 12 December 2008 21:03:14 Hugo Villeneuve, vous avez écrit : > > Hi, > > I have written some code to program a FPGA in Linux, for two > > different types of boards: one uses a serial interface (SPI) and > > the second a parallel interface. I have been able to sucessfully > > program both boards. I'm now trying to clean my code and make it > > more generic, as well as better in line with the Linux driver > > model. I would also like to include it in the mainline kernel if > > there is interest. > ... > What about something like that : > > - fpgaload-core which contains all the code that can be shared > between the drivers like requesting firmware, providing sysfs > attributes, > - fpgaload-spi would handle the low-level SPI connection > - fpgaload-par would handle the low-level parallel connection > > fpgaload-ser and par would register with fpgaload-core and they could > register a fpga loading callback which is low-level specific for > instance. Platform code would instantiate the core driver. That way, > adding support for other loading protocols like slave serial or > master serial can be done easily. Yes, but how I actually implement fpgaload_core, fpgaload_ser and fpgaload_par? Bus driver? class driver? platform driver? I am not sure how I should implement things and how each low-level specific driver should register with the fpgaload_core driver... Hugo V. --- Hugo Villeneuve www.hugovil.com --- -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
klaasjan gm wrote: Rob and to whom it may concern, I didn't discover this topic independently. Somebody pinged me about it on freenode back in February, and several other people sent me private email about it, and it's been previously raised on several other mailing lists (such as busybox and uclibc ones). Unfortunately, most of the embedded developers I know aren't subscribed to linux-kernel. FWIW, Hopefully the cc: to linux-embedded is helping get more embedded guys involved in the discussion than just me. :) Having some experience with cross-compiling the kernel, and some of the basic toolsets: I'm with you on this one (and testing the waters at linux-embedded while I'm at it) +1 Chris Regards, Klaasjan -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Sun, Jan 4, 2009 at 05:23, Leon Woestenberg wrote: > On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt wrote: >> Let's look at the rationale presented so far in this thread: >> >>2 - Cross-compiling perl is hard. > > 2 is not hard. i dont know where you're getting this mythical version of perl, but anything beyond micro-perl is a pita. and micro-perl is practically worthless. maybe for kernel/ -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
Rob and to whom it may concern, > I didn't discover this topic independently. Somebody pinged me about it on > freenode back in February, and several other people sent me private email > about it, and it's been previously raised on several other mailing lists (such > as busybox and uclibc ones). > > Unfortunately, most of the embedded developers I know aren't subscribed to > linux-kernel. FWIW, > Hopefully the cc: to linux-embedded is helping get more embedded guys involved > in the discussion than just me. :) Having some experience with cross-compiling the kernel, and some of the basic toolsets: I'm with you on this one (and testing the waters at linux-embedded while I'm at it) Regards, Klaasjan -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
