Linux on Memec Virtex II Pro V4P7 Rev. 3
Hello, I saw one of your posting on the web regarding writing to a compact flash on the Virtex II Pro V4P7 board. A problem that was encountered Was that the ISR needed to be disabled. I saw that you had a patch to fix this problem. ( nointr sysace patch). I would be greatly appreciated if Could send or let me know where if could find this patch. Would greatly appreciate your help. Tony. -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050324/8cc1f984/attachment.htm
Linux on Memec Virtex II Pro V4P7 Rev. 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Lee wrote: | On Sat, 9 Oct 2004 20:27:15 +0100, Jon Masters jonmasters at gmail.com wrote: | |On Thu, 7 Oct 2004 19:53:52 -0700, Tony Lee tony.p.lee at gmail.com wrote: | | |The problem I saw was that I can't turn off the interrupt at all. | |On the Memec board? really? | No, not on Memec, just on our own HW. Ah ok. Like you said, it's probably tied lines probably in the hardware definition at fault here. | I have the memec board, but I don't have time to play on that one. Ah ok. I have a wonderful mixture of Memec and custom board also. | I got to debug the HW one week after I was hired. Indeed. Fun huh. | As far as I can tell, our linux for memec board doesn't load | the sysace driver. Ok if you're not using it I guess. |Once I start one write command, the ISR keep coming in. |Ouch. | Tell me about it. It tooks me 3+ days to id this. It's taken me a long time on and off to fix these kinds of problem because of the usual case of balancing other bits and pieces. |Perhaps. But that's down to your hardware guys to check the error |output from your synthesis tool to see if this weirdly has happened. |Our board doesn't have lines hard tied together, if that was the |notion you were offering. | I tried to synthesize chipscope into into our VP20. It apparently doesn't work if you're using sysace inline on the same JTAG line that you want to use for chipscope interfacing. Having said that I've not used chipscope other than seeing a very biref demo, and I only heard this from a third party...so it might actually work ok. | It is less of a priority since the sysace is working | now for 1.5 months (without ISR). I also have moved on to fixing other bits, bodging in a NULL ioctl in smc9.c to handle ethtool requests that aren't wanted, etc. Usual case of fixing it up good enough for the current project and problem at hand but wanting to find a better solution for next time around. | Also, we use linux as Xilinux dev environment We don't mostly for historical reasons, but I'm planning on moving the development the way soon - I want this all nice and scriptable and this just aint gonna be pretty on Windows. [OT] I just spent two hours on a train with an MSFT employee sitting next to me...we didn't kill each other but had a variety of interesting conversation. |I try turn off the ISR on write with SYSACE register and |the ppc interrupt control register. None of them worked. |Did you do it as per my patch, or what? | No, where can I find your patch? In the list archives. It's only a quickie few lines, there's other stuff I need to cleaup. Having mentioned that, I'm still working on the stuff I mentioned in another thread on OpenFirmware tonight, having not got as far as I planned this weekend. Less sleep tonight then. |Yes. We come up in 8 seconds to my firmware, and total boot time is |around 20 seconds, without any effort to make it less. That includes |cunning DHCP+ZeroConf scripts I wrote. | That's about right, We don't do DHCP, it comes up a bit faster. I'd love to create a special interest group of Linux on Virtex II Pro users - not really a mailing list, just a group of us who use it and are willing to share experiences with eachother and perhaps newcomers as the documentation for all of this is shockingly absent :-). Jon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBabWXeTyyexZHHxERAtB9AJ4yfwsoMfABgwtSB5hZfIRafuszrgCbBM83 UBVQN83pPbwi1PnMpFvCg+0= =QH8A -END PGP SIGNATURE-
Linux on Memec Virtex II Pro V4P7 Rev. 3
On Thu, 7 Oct 2004 19:53:52 -0700, Tony Lee tony.p.lee at gmail.com wrote: The problem I saw was that I can't turn off the interrupt at all. On the Memec board? really? Once I start one write command, the ISR keep coming in. Ouch. I review the verilog code and schematic multiple times with the HW group but can't figure out what went wrong. We had to move one of the sysace lines to a different bank on the v2p but that was because we were cunningly running out of particular IO lines (the v2p does different signalling and voltages on different banks - I didn't make the modification as I don't work on the hardware directly, just mess with Xilinx hardware stuff in my spare time and software for them when at work :-) ). My best guess was the BUFRDY line is mix up with the ISR line Perhaps. But that's down to your hardware guys to check the error output from your synthesis tool to see if this weirdly has happened. Our board doesn't have lines hard tied together, if that was the notion you were offering. I try turn off the ISR on write with SYSACE register and the ppc interrupt control register. None of them worked. Did you do it as per my patch, or what? Do you think if we add a small DMA engine would help the performance or the performance problem is caused by the sysace firmware + the CF disk? Perhaps. I'll have a think about that - I'm certainly not going to get paid to do that, and until I can buy a v2p board for home or have some spare time in the office, it'll have to wait for an implementation. Kind of like porting to 2.6 and a whole bunch of other non-comercially useful things I want to do with this thing :-). The sysace controller IS VERY fast on loading the bitstream and linux boot image. Yes. We come up in 8 seconds to my firmware, and total boot time is around 20 seconds, without any effort to make it less. That includes cunning DHCP+ZeroConf scripts I wrote. Jon.
Linux on Memec Virtex II Pro V4P7 Rev. 3
On Sat, 9 Oct 2004 20:27:15 +0100, Jon Masters jonmasters at gmail.com wrote: On Thu, 7 Oct 2004 19:53:52 -0700, Tony Lee tony.p.lee at gmail.com wrote: The problem I saw was that I can't turn off the interrupt at all. On the Memec board? really? No, not on Memec, just on our own HW.I have the memec board, but I don't have time to play on that one. I got to debug the HW one week after I was hired.As far as I can tell, our linux for memec board doesn't load the sysace driver. Once I start one write command, the ISR keep coming in. Ouch. Tell me about it. It tooks me 3+ days to id this. Perhaps. But that's down to your hardware guys to check the error output from your synthesis tool to see if this weirdly has happened. Our board doesn't have lines hard tied together, if that was the notion you were offering. I tried to synthesize chipscope into into our VP20. But don't have much time for it now. It is less of a priority since the sysace is working now for 1.5 months (without ISR). Also, we use linux as Xilinux dev environment but the chipscope only work in Windows platform. Our HW folks don't have time to touch Windows side of Xilinx tools. It make it more difficult to debug SW/HW integration issue. I try turn off the ISR on write with SYSACE register and the ppc interrupt control register. None of them worked. Did you do it as per my patch, or what? No, where can I find your patch? Yes. We come up in 8 seconds to my firmware, and total boot time is around 20 seconds, without any effort to make it less. That includes cunning DHCP+ZeroConf scripts I wrote. That's about right, We don't do DHCP, it comes up a bit faster. -- -Tony Having a lot of fun with Xilinx Virtex Pro II reconfigurable HW + ppc + Linux
Linux on Memec Virtex II Pro V4P7 Rev. 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Lee wrote: | I have to use the non-interrupt mode in sysace. If necessary I will modify the quick patch I posted to use a CONFIG option but several of us are seeing problems with interrupts - I will change it to be the most useful for everyone, I suppose that means making it an option. | Jon, what kind of performance you got from the sysace? Crap. That's a technical term. The chip IMO has some fundamental issues which really need to get resolved in a rev - it takes on the order of several minutes to commit writes with a sync however we rarely have to write to the flash and usually only store small parameter files. | When I copy 18 MB of ace file into sysace with Linux, the | sync command took minutes to complete for me. Where this affects you and I is likely in writes to update the hardware image with a new one that you have sent to the customer as a firmware upgrade to be installed. It takes ages for me too - but this is a rare enough thing that we can live with it for the moment. | Sysace ISR should not be the issue, since there is no seeks | and all the IO is dirven from the kernel. The polled approach is worse IMO although I agree that there is very little overhead in the actual ISR. Where the author went wrong (well perhaps not wrong per se but didn't provide enough protection) was in the unlikely case that the hardware is braindead and generates interrupts that you didn't ask it to - the xsysace driver should also catch interrupts when we're QUEUE_EMPTY and should not try to manipulate an empty request queue. Jon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBZduDeTyyexZHHxERArI0AJ9zd7sRSnO6dZBYw/G3NpuqjNqe7wCgixC0 /eRaHY5fhfUVW7TAFRtCrQM= =3n0G -END PGP SIGNATURE-
Linux on Memec Virtex II Pro V4P7 Rev. 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrei Konovalov wrote: | Do you use EDK for your desing? jcm EDK gets used for bits of it but then treated as a black box which jcm goes in to various other design tools. I don't rely upon any defines jcm EDK generates for me as I don't trust them ;-). | I see. The bitstream (ACE file) is generated with EDK, | autogenerated BSP is mostly ignored. Thing is, EDK is good at certain things but Synplify and other tools are much better at overal project design so we build the platform in EDK and then treat it as a black box in a much larger design. I use a bunch of scripts and the dummy.o type behaviour of a kernel build to bodge in my own firmware with kernel and root initrd in a single image which can be loaded by the sysace. It works better than most examples I have seen. | I use the Linux version of their tools. cygwin is not a 100% replacement | for Linux. I'd like to but there are various reasons why that's impractical at the moment - eventually I'm going to fix this and use the ported tools. Certainly they could have done a much better job with xygwin as they severely limit what I can script in some of my Makefiles. | I guess you do not use what Xilinx calls OS independent drivers (== | HAL?) too then. jcm I use them only for xsysace because I looked in to rewriting your jcm driver to not do that but it would take too long. I'm still planning jcm to rewrite it though to not use their HAL concept. It's a really bad jcm idea to rely upon third party HAL code in the kernel itself and should jcm not be done - instead the kernel needs to be able to be given jcm parameters at run time and do the driver work itself. The xsysace jcm adapter stuff it not pretty (though you guys did a good job, thanks) jcm and really doesn't want to be implemented that way. | Understand. I think rewriting UART Lite or probably xsysace not to | use HAL code is not a tremendous effort. No it's not. But it does take more than an afternoon to get working properly and I have other more pressing issues to sort first. | IMHO more complex drivers like ethernet in SGDMA mode is a problem: Yes. Luckily I wouldn't use the Xilinx ethernet MAC unless there were few alternatives, since I've heard only negative things about it. It apparently occupies a large amount of chip resources and has a few other issues that have yet to be fully resolved, hardware MACs are cheap. | While we're on this subject I will ask - do you also need something | like the nointr mods I pointed out in order to use sysace for writing | on that board? The hardware generates more interrupts than anything | documented suggests that it should and your driver dies horribly (or | is completely unreliable) unless I modify it as I mentioned. It's | probably a sysaceism. | Not too much to say about sysace at the moment. | We do not use xsysace in our Memec 2VP7 design I thought you probably didn't. We/I have this cunning thought that very few people are actually using sysace for read/write filesystems. | I was just asked to try to enhance the xsysace driver performance - | will use this opportunity to have a deeper look at the driver's internals. I spent a long time going through your driver code (where you is whoever at Monta wrote it in combination with Xilinx) and can say that, while it isn't pretty, I can't fault it. There's nothing in there which is horribly buggy and wrong despite the xsa_thread concept which ac agrees is a really bad idea in theory (but you end up having to use it to make this xsysace driver work) :-). Jon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBZJXxeTyyexZHHxERAv3eAJ9/w42mIMEG0ghJBx7+BKu8GooB6ACcC+KQ 5G3HoMvX8a4cW+YbGIUgMZU= =8FCM -END PGP SIGNATURE-
Linux on Memec Virtex II Pro V4P7 Rev. 3
On Wed, 06 Oct 2004 19:41:22 +0400, Andrei Konovalov akonovalov at ru.mvista.com wrote: Jon Masters wrote: On Tue, 05 Oct 2004 20:05:29 +0400, Andrei Konovalov akonovalov at ru.mvista.com wrote: While we're on this subject I will ask - do you also need something like the nointr mods I pointed out in order to use sysace for writing on that board? The hardware generates more interrupts than anything documented suggests that it should and your driver dies horribly (or is completely unreliable) unless I modify it as I mentioned. It's probably a sysaceism. Not too much to say about sysace at the moment. We do not use xsysace in our Memec 2VP7 design (this is a chip select issue with P160 flash and xsysace sitting on the same bus - we do not have HW engineer to do an IP to control the chip select inputs; by default both are tied to ground - always selected). With ML300 we've never seen this problem. I was just asked to try to enhance the xsysace driver performance - will use this opportunity to have a deeper look at the driver's internals. I have to use the non-interrupt mode in sysace. I thought there were some HW issue in our HW board (no ML 300). Good to know other have the same problem. We don't have ML300, otherwise, I will run the kernel with printk in the sysace driver to see that system ISR behavior on write. The problem I had was: I can not turn off the ISR when write to the system (nor when send ID drive command). Jon, what kind of performance you got from the sysace? When I copy 18 MB of ace file into sysace with Linux, the sync command took minutes to complete for me. Sysace ISR should not be the issue, since there is no seeks and all the IO is dirven from the kernel. -- -Tony
Linux on Memec Virtex II Pro V4P7 Rev. 3
On Fri, 08 Oct 2004 01:12:51 +0100, Jon Masters jonathan at jonmasters.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The polled approach is worse IMO although I agree that there is very little overhead in the actual ISR. Where the author went wrong (well perhaps not wrong per se but didn't provide enough protection) was in the unlikely case that the hardware is braindead and generates interrupts that you didn't ask it to - the xsysace driver should also catch interrupts when we're QUEUE_EMPTY and should not try to manipulate an empty request queue. Jon. The problem I saw was that I can't turn off the interrupt at all. Once I start one write command, the ISR keep coming in. I review the verilog code and schematic multiple times with the HW group but can't figure out what went wrong. My best guess was the BUFRDY line is mix up with the ISR line some how when write cmd and when IDEN drive command is issued. I try turn off the ISR on write with SYSACE register and the ppc interrupt control register. None of them worked. Jon, Do you think if we add a small DMA engine would help the performance or the performance problem is caused by the sysace firmware + the CF disk? The sysace controller IS VERY fast on loading the bitstream and linux boot image. -- -Tony Having a lot of fun with Xilinx Virtex Pro II reconfigurable HW + ppc + Linux
Linux on Memec Virtex II Pro V4P7 Rev. 3
On Tue, 05 Oct 2004 20:05:29 +0400, Andrei Konovalov akonovalov at ru.mvista.com wrote: Jon Masters wrote: You need a few extra patches such as the one to use even TLBs only that I and others ended up implementing on the engineering v2ps. This one does present in the patch from Mind.be. Look for CONFIG_IBM405D5XN_TLB_BUG in patch-platform-insightv2pro. They've added it since I think - I had thought they had done. It's necessary elsewhere too so I wouldn't get too worked up about that. The Monta guys don't get this problem on their shiney ML300s but then if I wanted to expense 6K to Xilinx for a touchscreen board I might buy one too :-). We have the Memec board running as well. Well great :-). With P160 COMM module though. It's not worth using the P160 module most of the time though it's good for a dev board. The EDK stuff sucks horribly - avoid the autogenerated platforms beyond the necessary. Certainly don't use the xparms file from EDK in your design, that supports the notion Xilinx have of shoving a HAL in to the kernel. Do you use EDK for your desing? EDK gets used for bits of it but then treated as a black box which goes in to various other design tools. I don't rely upon any defines EDK generates for me as I don't trust them ;-). If yes, how do you get the addresses etc from you design without using xparams? I've modified most of the drivers I use to have defines, or used an xparameters.h for some stuff but written it by hand without relying upon the EDK generation tools. They managed to get the MHS out of sync with the design one too many times for me to trust them for a long long time with parameters. For example, turning on the MMU had us racking our brains to figure out why it wasn't working as it should - turned out the EDK design tool had itself out of sync. I've moaned at various people I've met from Xilinx that the overall tools are ok (xygwin causes nice issues with cygwin dlls sometimes and should come with basic utilities such as less and more) and I use them, but I won't be jumping for the notion of having their tool generate a BSP for my use because it's not the place of their tools to do this kind of thing IMO. Do you use the mhs file for this? Effectively yes. I produce the equivalents by hand at the moment - there is an xparameters file for bits I don't care to change in generic drivers, but it's done by hand. I guess you do not use what Xilinx calls OS independent drivers (== HAL?) too then. I use them only for xsysace because I looked in to rewriting your driver to not do that but it would take too long. I'm still planning to rewrite it though to not use their HAL concept. It's a really bad idea to rely upon third party HAL code in the kernel itself and should not be done - instead the kernel needs to be able to be given parameters at run time and do the driver work itself. The xsysace adapter stuff it not pretty (though you guys did a good job, thanks) and really doesn't want to be implemented that way. While we're on this subject I will ask - do you also need something like the nointr mods I pointed out in order to use sysace for writing on that board? The hardware generates more interrupts than anything documented suggests that it should and your driver dies horribly (or is completely unreliable) unless I modify it as I mentioned. It's probably a sysaceism. Cheers, Jon.
Linux on Memec Virtex II Pro V4P7 Rev. 3
[ Will followup only to linuxppc-embedded ] On Tue, 5 Oct 2004 13:26:15 +0200, Luca Giuliani l.giuliani at tiscali.it wrote: I'm a newbie of Linux on embedded devices and I tried longly to make Linux work on the embedded PPC405 on the Memec Virtex II Prov V4P7 board I have one of these boards which we base our platform upon. WITHOUT P160 module. I use an SMC9 on a custom ISA bodge - no P160 here but we do also use xuart et al. (Why would you want to buy the Xilinx Ethernet MAC or use the P160 anyway - who needs a second serial port :P). I'm using the patched 2.4.22 patched by Mind.be, freely available on their FTP site. You need a few extra patches such as the one to use even TLBs only that I and others ended up implementing on the engineering v2ps. I'll stick up my mods at some point (product not shipping at this moment so this'll be done at some point before then). The boot process always freezes after the Uncompressing Linux...done There's a bunch of problems with that board. You end up disabling the ME reporting on those boards by bodging the MSR as you mentioned. That's a bastard to figure out. The only way to make the kernel INITIATE the boot process was to modify the MSR mask (/include/asm-ppc/processor.h) as to disable the Machine Check, but this is not a good idea! It's necessary elsewhere too so I wouldn't get too worked up about that. The Monta guys don't get this problem on their shiney ML300s but then if I wanted to expense 6K to Xilinx for a touchscreen board I might buy one too :-). The first thing that came to my mind was that there was an error in the hardware design, but it was auto-generated with the Base platform builder wizard included in EDK 6.2 and then customized only to meet the requirements of the Mind kernel. The EDK stuff sucks horribly - avoid the autogenerated platforms beyond the necessary. Certainly don't use the xparms file from EDK in your design, that supports the notion Xilinx have of shoving a HAL in to the kernel. Has someone succeeded in booting Linux on this device WITHOUT P160 expansion card? Yes. Spam me. If so I kindly ask you to answer me privately, at least to know how you built the hardware design, which kernel did you use and which are the vital parameters to be set in the kernel. A custom 2.4.23 based purely on the stock kernel from kernel.org. I use a few Mind patches, some stuff from the Monta tree and a bunch of hacks I did myself. It boots using my own firmware which is in the hardware image on the SystemACE and runs with a root RAMdisk off the sysace (but you need to use my nointr sysace patch for this board). I can help you with generalities but for various commerical reasons there's a limit to how much I can talk about here or in private mail concerning our specific design. Cheers, Jon.
Linux on Memec Virtex II Pro V4P7 Rev. 3
Jon Masters wrote: [ Will followup only to linuxppc-embedded ] On Tue, 5 Oct 2004 13:26:15 +0200, Luca Giuliani l.giuliani at tiscali.it wrote: ... I'm using the patched 2.4.22 patched by Mind.be, freely available on their FTP site. You need a few extra patches such as the one to use even TLBs only that I and others ended up implementing on the engineering v2ps. This one does present in the patch from Mind.be. Look for CONFIG_IBM405D5XN_TLB_BUG in patch-platform-insightv2pro. ... It's necessary elsewhere too so I wouldn't get too worked up about that. The Monta guys don't get this problem on their shiney ML300s but then if I wanted to expense 6K to Xilinx for a touchscreen board I might buy one too :-). We have the Memec board running as well. With P160 COMM module though. I've posted the patch last Friday, but it got into the bi_recs thread - my fault (hopefully doesn't affect those not reading the archives). ... The EDK stuff sucks horribly - avoid the autogenerated platforms beyond the necessary. Certainly don't use the xparms file from EDK in your design, that supports the notion Xilinx have of shoving a HAL in to the kernel. Jon, Do you use EDK for your desing? If yes, how do you get the addresses etc from you design without using xparams? Do you use the mhs file for this? I guess you do not use what Xilinx calls OS independent drivers (== HAL?) too then. ... Thanks, Andrei
[MailServer Resend]Resending quarantined email -- use caution when opening.Re: Linux on Memec Virtex II Pro V4P7 Rev. 3
Warning: Attachment contains virus code or meets the filtering/blocking rules. Use caution when accessing the contents. - Original Message Header - Subject: Re: Linux on Memec Virtex II Pro V4P7 Rev. 3 From: Jon Masters To: Luca Giuliani Cc: linuxppc-dev at ozlabs.org; linuxppc-embedded at ozlabs.org --- -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20041005/9ffbaa04/attachment.htm -- next part -- An embedded message was scrubbed... From: Jon Masters [EMAIL PROTECTED] Subject: Re: Linux on Memec Virtex II Pro V4P7 Rev. 3 Date: Tue, 5 Oct 2004 11:15:33 -0400 Size: 2790 Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20041005/9ffbaa04/attachment.eml -- next part -- A non-text attachment was scrubbed... Name: Msgbody1.doc Type: application/octet-stream Size: 3090 bytes Desc: Msgbody1.doc Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20041005/9ffbaa04/attachment.obj
Linux on Memec Virtex II Pro V4P7 Rev. 3
Sorry folks... I am trying to get our IT department to turn off their scanning software, or to configure it correctly... I am hoping not to have to resort to subscribing from my non-work address but it might just come to that. And now back to regularly scheduled embedded discussions. -R
Linux on the Virtex II Pro?
Dear John, in message C7FFFEA58B43D311920D0004ACE5333F0F53583A at amer25.avnet.com you wrote: If I keep mentioning ELDK a lot, it's because: Thanks for the friendly words... * ELDK supports multiple PPC families (e.g. 4xx, 8xx, 82xx, ...) as well as ARM. ... and MIPS. * Did I mention it's not expensive ... = free for download. to re-invent the wheel anymore. You can spent your time on more advanced automotive engineering. :) Happy hacking. Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux on the Virtex II Pro?- ELDK?
In message 3F0E0C91.1000209 at irtf.ifa.hawaii.edu you wrote: Is it possible to use the ELDK to compile a simple stand alone executable that I could download and start using my jtag interface? I Yes, of course tis is possible. We use the ELDK for example to build the U-Boot boot loader on a plethora of systems - which is nothing else but a (bigger) standalone executable. You will have to be careful about assumptions about: - C runtime envrionment (there is none, or you have to set it up yourself) - library usage (standard C libs require full C runtime envrionment plus some other things like standard file descriptors, etc.) Feel free to have a look at U-Boot... tried compiling a really trivial piece of code with the -static option, and it created a file that looks large enough to have included everything it needs but when I download and start it, I don't see any of the break points I'm setting being triggered. How did you set up your C runtim environment, for example: allocate a stack, initialize the parent stack frame, etc. ? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Once at a social gathering, Gladstone said to Disraeli, I predict, Sir, that you will die either by hanging or of some vile disease. Disraeli replied, That all depends, Sir, upon whether I embrace your principles or your mistress. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux on the Virtex II Pro?
Current Linux/PPC trees already include support for 405 as well as the Xilinx ML300 board. (The Linux/PPC tree I got had slightly stale libgen'ed code, which I simply replaced with current libgen'ed code from my XPS project.) I can send you a patch file on request. At the beginning of July the linuxppc_2_4_devel tree has been updated with the drivers shipping with EDK 3.2 SP2. Further, all necessary changes have been pushed to move from V2PDK to EDK (interrupt controller bit ordering, System ACE byte/word addressing, etc.). Unfortunately, the on-going changes to the OCP implementation (not Virtex-II Pro related) break the kernel compilation for ML300. - Peter http://www.xilinx.com/ml300 http://www.xilinx.com/edk ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux on the Virtex II Pro?- ELDK?
Charles, Yes, this also can be done. In fact, I use ELDK's ppc_[48]xx-gcc to build the kernel, Linux apps, and standalone apps. In particuar, I use ppc_[48]xx-gcc to build the firmware that loads the OS. And of course ppc_8xx-gcc/ppc_4xx-gcc is used to build U-Boot. Your biggest whangup will probably be the C library -- strcpy() et al. are easy to code up, but most people find that making a printf() takes a bit more work. If you don't already have such library routines written, you might take a peek a U-Boot. And you want a simple crt0.S which zero-fills the BSS (_edata to _end), sets the stack pointer and jumps into main. Also you are responsible for direct access to the UART hardware etc. but the good news is that a simple polled-mode driver for a standalone application is generally an order of magnitude simpler than a real driver for an OS in which you would need to think about interrupts, context switching, etc. [Virtex-II Pro note: If you want to build a standalone app using Xilinx libgen'ed libraries, (1) you might use their powerpc-eabi-gcc instead. Or, (2) you might use ELDK's ppc_4xx-gcc but include XPS's lib binaries; I haven't tried that. (3) You can use libgen'ed source code, compile with ELDK. (4) You can dispense with the libgen'ed stuff and write your own drivers. This latter might be preferable for simple devices such as UART lite and the INTC.] Having said that ... due to size restrictions, I won't attach a sample makefile to everyone on the list. However, I'll forward it to you separately, and will send a copy to anyone else who requests it. The essence, though, is: ppc_4xx-ld -s -Bstatic -Ttext 0x0050 $(OBJS) -o myfile.elf -Lwherever Then ppc_4xx-objcopy -O binary myfile.elf myfile.mem if you want a plain binary. -Original Message- From: Charles Lockhart [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 6:02 PM To: linuxppc-embedded at lists.linuxppc.org Subject: Re: Linux on the Virtex II Pro?- ELDK? Is it possible to use the ELDK to compile a simple stand alone executable that I could download and start using my jtag interface? I tried compiling a really trivial piece of code with the -static option, and it created a file that looks large enough to have included everything it needs but when I download and start it, I don't see any of the break points I'm setting being triggered. I'd just like to do this as kind of a litmus test to show that I can build something at least that'll execute. -Charles Lockhart ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux on the Virtex II Pro?
On Thursday, July 10, 2003, at 01:35 PM, Charles Lockhart wrote: I was looking to see who supports the Virtex2Pro chip for Linux? In terms of a tool chain, support, etc? Has anyone tried building a custom tool chain for it on their own? Results? It sounds like you are interested in a commercial solution, so I thought I would mention that MontaVista Software (www.mvista.com) supports the Xilinx ML300 and did the port and drivers for it that you see in linuxppc_2_4_devel. Good luck on your project, Scott Anderson MontaVista Software ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux on the Virtex II Pro?
Charles, For our Virtex-II Pro board I used ELDK with minor mods, mostly for my board. Current Linux/PPC trees already include support for 405 as well as the Xilinx ML300 board. (The Linux/PPC tree I got had slightly stale libgen'ed code, which I simply replaced with current libgen'ed code from my XPS project.) I can send you a patch file on request. A couple years ago (before ELDK was released) I built a toolchain from scratch, thinking I'd learn something in the process. What I learned was that it's a pain. My $0.02 is that you're better off using pre-compiled tool chains (e.g. ELDK). If I keep mentioning ELDK a lot, it's because: * Denx has already done this right. You can do it all over again yourself, but (a) you'd been spending time building tool chains, RAM disks, etc. which you could have gotten easily, and (b) you would be hard pressed to do a better job of it than Denx already has. * The ELDK build environment comes with nice RPM packaging. * The ELDK runtime environment comes with nice init-style startup. * ELDK supports multiple PPC families (e.g. 4xx, 8xx, 82xx, ...) as well as ARM. * Did I mention it's not expensive ... Denx Software has done a great service for the embedded Linux community: if you read back through this mailing list, you'll see that many people (including myself) re-invented the wheel, over and over again. People would have a bare board, apparently get a kernel from somewhere, get some GCC source code, and start hacking. It was a sad thing. Now, with ELDK out, you don't have to re-invent the wheel anymore. You can spent your time on more advanced automotive engineering. :) -Original Message- From: Charles Lockhart [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 1:36 PM To: linuxppc-embedded at lists.linuxppc.org Subject: Linux on the Virtex II Pro? Hello, I was looking to see who supports the Virtex2Pro chip for Linux? In terms of a tool chain, support, etc? Has anyone tried building a custom tool chain for it on their own? Results? Thanks, -Charles Lockhart ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux on the Virtex II Pro?- ELDK?
Is it possible to use the ELDK to compile a simple stand alone executable that I could download and start using my jtag interface? I tried compiling a really trivial piece of code with the -static option, and it created a file that looks large enough to have included everything it needs but when I download and start it, I don't see any of the break points I'm setting being triggered. I'd just like to do this as kind of a litmus test to show that I can build something at least that'll execute. -Charles Lockhart ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
