http://permalink.gmane.org/gmane.linux.uclinux.microblaze hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11846 <pre>Hi Graeme, On Tue, Apr 17, 2012 at 8:10 AM, Graeme Smecher &lt;gsmecher-nnnUIkgvSzgE8ZBZu6QcQEEOCMrvLtNR&lt; at &gt;public.gmane.org&gt; wrote: Yup. linuxthreads needs to be put out to pasture. Thanks. The release is imminent. We are ironing out the last few remaining issues in testing now. Getting it upstream is also part of the plan, along with securing a commitment to maintain it there. Stay tuned! Rgds, John </pre> John Williams 2012-04-16T23:21:40 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11845 <pre>Hi all, For some time, I've been butting heads with Microblaze's linuxthreads-based toolchain. A nptl-based libc would be an exciting development. For me, the chief benefit is futex-based semaphores, which allows sem_init with pshared=1 (and makes it go fast too!) So, I'm really excited to see Michal's message to lkml about a month ago: http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/04188.html First off: congratulations. Linux on MicroBlaze has come a tremendous distance in the past few years, and this is one of the few remaining things on my wish list. Do you have any hints about when and how we'll see the next toolchain upgrade? best, Graeme _______________________________________________ microblaze-linux mailing list microblaze-linux-FR6EJeJVuqfA6Z3fQjNZrN9u6TNh0Fb7&lt; at &gt;public.gmane.org https://lists.eait.uq.edu.au/mailman/listinfo/microblaze-linux </pre> Graeme Smecher 2012-04-16T22:10:46 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11840 <pre> Tested-by: Michal Simek &lt;monstr-pSz03upnqPeHXe+LvDLADg&lt; at &gt;public.gmane.org&gt; Grant: This driver should go through your tree. If you don't want to add it there, I have no problem to add it to mine and provide path to mainline. Thanks, Michal </pre> Michal Simek 2012-04-10T11:49:01 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11839 <pre>This fixes a bug introduced in 5d10302f46d, where device trees that don't provide the "port-number" attribute are mistakenly assigned the device "xs`". The error check that's supposed to assign a default letter can't succeed, since it tests an unsigned type against a negative return code. Signed-off-by: Graeme Smecher &lt;gsmecher-nnnUIkgvSzgE8ZBZu6QcQEEOCMrvLtNR&lt; at &gt;public.gmane.org&gt; Acked-by: Grant Likely &lt;grant.likely-s3s/WqlpOiPyB63q8FvJNQ&lt; at &gt;public.gmane.org&gt; --- drivers/block/xsysace.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c index 307e098..a18de18 100644 --- a/drivers/block/xsysace.c +++ b/drivers/block/xsysace.c &lt; at &gt;&lt; at &gt; -1166,8 +1166,7 &lt; at &gt;&lt; at &gt; static int __devinit ace_probe(struct platform_device *dev) dev_dbg(&amp;dev-&gt;dev, "ace_probe(%p)\n", dev); /* device id and bus width */ -of_property_read_u32(dev-&gt;dev.of_node, "port-number", &amp;id); -if (id &lt; 0) +if (of_property_read_u32(dev-&gt;dev.of_node, "port-number", &amp;id)) id = 0; if</pre> Graeme Smecher 2012-04-09T19:29:04 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11838 <pre> Aside from trivial coding style violation (there needs to be a space between 'if' and '('): Acked-by: Grant Likely &lt;grant.likely-s3s/WqlpOiPyB63q8FvJNQ&lt; at &gt;public.gmane.org&gt; </pre> Grant Likely 2012-04-07T03:17:33 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11837 <pre>Hi Graeme, On Wed, Apr 4, 2012 at 4:39 AM, Graeme Smecher &lt;gsmecher-nnnUIkgvSzgE8ZBZu6QcQEEOCMrvLtNR&lt; at &gt;public.gmane.org&gt; wrote: ... Thanks for the followup. You asked about FPGA config, most of the designs we are seeing are using a SPI or NOR flash with one or more FPGA partitions using standard Xilinx multiboot approaches. Linux / MTD manages the flash partitions so there's just an extra one at the bottom of flash for the FPGA config. Makes it nice and easy then to do full system firmware upgrades. We've built standard capability for this into petalinux - creating firmware bundles on the tools side, and applying/installing them on the runtime side. We saw too many customers wanting or creating custom solutions so we just built something that is simple and effective. Cheers, John </pre> John Williams 2012-04-04T23:44:45 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11836 <pre>This fixes a bug introduced in 5d10302f46d, where device trees that don't provide the "port-number" attribute are mistakenly assigned the device "xs`". The error check that's supposed to assign a default letter can't succeed, since it tests an unsigned type against a negative return code. Signed-off-by: Graeme Smecher &lt;gsmecher-nnnUIkgvSzgE8ZBZu6QcQEEOCMrvLtNR&lt; at &gt;public.gmane.org&gt; --- drivers/block/xsysace.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c index 307e098..ab30495 100644 --- a/drivers/block/xsysace.c +++ b/drivers/block/xsysace.c &lt; at &gt;&lt; at &gt; -1166,8 +1166,7 &lt; at &gt;&lt; at &gt; static int __devinit ace_probe(struct platform_device *dev) dev_dbg(&amp;dev-&gt;dev, "ace_probe(%p)\n", dev); /* device id and bus width */ -of_property_read_u32(dev-&gt;dev.of_node, "port-number", &amp;id); -if (id &lt; 0) +if(of_property_read_u32(dev-&gt;dev.of_node, "port-number", &amp;id)) id = 0; if (of_find_property(dev-&gt;dev.of_node, "8-bit", NULL)) bus_width = ACE_BUS_WID</pre> Graeme Smecher 2012-04-03T23:52:36 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11835 <pre>Hi all, On 07/03/12 03:56 PM, Graeme Smecher wrote: Here's a summary for the archives. Yes, the xsysace driver and the TSTJTAG port conflict with each other. To get JTAG readback and CompactFlash access to coexist, I made a few changes to the driver (xsysace.c): * Don't place the configuration controller in reset (i.e. don't assert ACE_CTRL_CFGRESET) * Don't enable error IRQs (otherwise they arrive in spades, and I'm flooded with syslog messages) These changes contradict the SysACE datasheet, which says: Note: It is important to assert CFGRESET='1' while accessing the CompactFlash card sector data via the MPU port, otherwise a CFGERROR condition could result. With these changes in place, I'm able to access CompactFlash data (from the Microblaze), while a simultaneous bitstream readback/verification is occurring via TSTJTAG. I'm not completely satisfied with this fix since the configuration error causes the SysACE's error LED to illuminate, and stay illuminated, shortly after </pre> Graeme Smecher 2012-04-03T18:39:33 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11829 <pre>HI David, On 15 March 2012 21:57, David Howells &lt;dhowells-H+wXaHxf7aLQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt; wrote: There are two compilation errors. I have created patch to fix it. Will add it to mainline through my microblaze repo. Next time please copy directly me &lt;monstr-pSz03upnqPeHXe+LvDLADg&lt; at &gt;public.gmane.org&gt; instead of mailng list. Thanks, Michal </pre> Michal Simek 2012-03-30T09:58:22 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11785 <pre>Hi John, On 15/03/12 08:10 PM, John Williams wrote Out of interest -- if you are getting bitstreams off of removable storage, how are you doing it these days? We're planning a Kintex-7 board right now, and the SysACE on our Virtex-4 boards is big, expensive, and showing its wrinkles. On our most recent Spartan-6 board, we replaced the SystemACE with a combination of SPI flash (for bitstreams) and MicroSD (for the filesystem). Both interfaces are pretty slow, and we miss having the entire build on a single, removable piece of storage we can keep in a drawer. I agree... and I'm pretty sure this problem didn't exist on our older (Linux 2.4) build. I'm hoping we're running into either (a) something subtle that's my fault, or (b) a problem we can dodge by avoiding problematic SysACE register combinations. Thanks, I should have gone there first. I've got a WebCase open, and I'll summarize the results here if they aren't too personally embarrassing. cheers, Graeme _______________________________</pre> Graeme Smecher 2012-03-16T16:12:45 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11784 <pre>Hi Graeme, On Thu, Mar 8, 2012 at 9:56 AM, Graeme Smecher &lt;gsmecher-nnnUIkgvSzgE8ZBZu6QcQEEOCMrvLtNR&lt; at &gt;public.gmane.org&gt; wrote: Haven't seen it but honestly our use of SysACE these days as almost zero. interface IP) uses JTAG to drive the whole boot process. So it doesn't surprise me that there might be some conflicts. That said, it also seems likely that Xilinx would have planned for this. Nothing concrete to offer I'm afraid, have you tried the Xilinx forums? Cheers, John </pre> John Williams 2012-03-16T03:10:54 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11777 <pre>Hi all, I'm using Linux 2.6.38 on a ML40x-like platform. We're booting off the SystemACE, with a FAT partition for bitstreams and an EXT2 partition for the filesystem. All very standard stuff. We're also using the SystemACE's JTAG port (TSTJTAG) to perform active readback and verification on the FPGA's bitstream. This works perfectly while the CF card is inactive (e.g. with the kernel running either from a RAMdisk, or once everything's cached in RAM.) However, as soon as bitstream readback and CF accesses overlap, the kernel and/or readback fail in one of several ways: * data read from the CompactFlash is corrupt (and since it gets cached in the kernel, Linux sees a consistently corrupt file until the VM is flushed via /proc/sys/vm/drop_caches), and/or * the readback returns bogus data, and/or * the FPGA freaks out and enters a high-impedance state. It seems like the JTAG and CF portions of the system are wrestling over the SystemACE. My questions are: * Has anyone else exp</pre> Graeme Smecher 2012-03-07T23:56:15 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11757 <pre> On 2012/03/06, at 04:30, Aws Ismail wrote: Yes. UIO is very nice. But it appeared only on Linux kernel 2.6.23 ( http://kernelnewbies.org/Linux_2_6_23 ). Some of us are still working with kernel 2.6.20 ( Petalinux 0.40 final). Another alternative with a recent kernel would be creating a VDSO: http://www.linuxjournal.com/content/creating-vdso-colonels-other-chicken http://lwn.net/Articles/446528/ But I don't know if this exists for Microblaze ( It works on i386, x86_64 and PowerPC). My best regards Paulo Ferreira _______________________________________________ microblaze-linux mailing list microblaze-linux-FR6EJeJVuqfA6Z3fQjNZrN9u6TNh0Fb7&lt; at &gt;public.gmane.org https://lists.eait.uq.edu.au/mailman/listinfo/microblaze-linux </pre> Paulo Ferreira 2012-03-07T08:45:01 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11756 <pre>Hi, Stephen, It seems that UIMAGE_ARCH and UIMAGE_LOADADDR can't be modified from arch-Makefiles. Regards, Guan Xuetao _______________________________________________ microblaze-linux mailing list microblaze-linux-FR6EJeJVuqfA6Z3fQjNZrN9u6TNh0Fb7&lt; at &gt;public.gmane.org https://lists.eait.uq.edu.au/mailman/listinfo/microblaze-linux </pre> Guan Xuetao 2012-03-07T06:52:43 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11750 <pre>Am Montag, den 05.03.2012, 20:30 -0800 schrieb Aws Ismail: Hi yes, you can use the generic UIO platform driver for this (expand the device tree as you need). You will find it in drivers/uio (Kconfig: UIO_PDRV and UIO_PDRV_GENIRQ). The device tree part correspond with your specific registers should looks like this (without interrupt directions): mbref_reg_0: uio&lt; at &gt;80800000 { compatible = "xlnx,plbv46-mbref-reg-1.00.a", "generic-uio"; interrupt-parent = &lt;&amp;xps_intc_0&gt;; interrupts = &lt; 9 2 &gt;; reg = &lt; 0x80800000 0x10000 &gt;; xlnx,family = "virtex6"; xlnx,include-dphase-timer = &lt;0x1&gt;; } ; In user space you can use the programming library libUIO or libuio. br, Stephan _______________________________________________ microblaze-linux mailing list microblaze-linux-FR6EJeJVuqfA6Z3fQjNZrN9u6TNh0Fb7&lt; at &gt;public.gmane.org https://lists.eait.uq.edu.au/mailman/listinfo/microblaze-linux </pre> Stephan Linz 2012-03-06T18:02:06 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11749 <pre>Hi. In addition of the two solutions by Grame and Paulo, I would suggest looking at the User IO framework (UIO) where you don't need to worry about writing and debugging kernel space code (i.e. LKMs or simple device drivers). Instead you deal with all the data IO from the user space in a safe manner. The last time I checked, UIO can be enabled from when configuring the kernel image (ala make menuconfig). Cheers. ------------------------------ Aws Ismail ------------------------------ On Thu, Mar 1, 2012 at 10:38 AM, Oliver Punk &lt;oliver.punk-MYXGEobB3FdQJivYmOibdQ&lt; at &gt;public.gmane.org&gt;wrote: _______________________________________________ microblaze-linux mailing list microblaze-linux-FR6EJeJVuqfA6Z3fQjNZrN9u6TNh0Fb7&lt; at &gt;public.gmane.org https://lists.eait.uq.edu.au/mailman/listinfo/microblaze-linux </pre> Aws Ismail 2012-03-06T04:30:53 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11748 <pre> On 2012/03/01, at 18:38, Oliver Punk wrote: Do you really need a kernel module? Dou you really need writes from the custom core? The "fast and cheap" way of doing it, would be mapping a bit of the custom core memory on the Microblaze physical address bus. Then the data is available to the Microblaze and you can access it like this: http://wiki.xilinx.com/osl-user-mode-pseudo-driver It may not be the best solution but it works.... My best regards Paulo Ferreira _______________________________________________ microblaze-linux mailing list microblaze-linux-FR6EJeJVuqfA6Z3fQjNZrN9u6TNh0Fb7&lt; at &gt;public.gmane.org https://lists.eait.uq.edu.au/mailman/listinfo/microblaze-linux </pre> Paulo Ferreira 2012-03-01T20:02:38 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11747 <pre>Hello I probably have a very trivial problem: I have a custom core which has three registers. In the first register I put a physical memory address, in the second I put a count. The I put a flag in the third, and the core writes some stuff on the address from reg 1. Standalone, It works perfect. Now I want to access the core by Linux about a kernel module. I call this module by an application and give the count and an address, which I have "calloct" in user space. Unfortunately the adress (virtual ?) dosnt mach with the physical address. __pa doesnt work. Is there a conversion as a function? Or did I think a huge mistake? Probably I need to studying intensively with the memory handling. But eventually someone has a quick answer or a good link. Thanks a lot. Oli _______________________________________________ microblaze-linux mailing list microblaze-linux-FR6EJeJVuqfA6Z3fQjNZrN9u6TNh0Fb7&lt; at &gt;public.gmane.org https://lists.eait.uq.edu.au/mailman/listinfo/microblaze-linux </pre> Oliver Punk 2012-03-01T18:38:12 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11743 <pre>CALL FOR PAPERS The 2nd Embed With Linux (EWiLi) Workshop Submission deadline: 4 March 2012 7 June 2012, Cité de la voile, Lorient, France http://www.sigops-france.fr/EWiLi Workshop news: - 10 days left for submission. - Very attractive registration costs (approximately ~50€ for authors) / free for PhD students - A showroom session for Industrial Exhibition and posters will also take place during the workshop (the web site will soon be updated for industrial exhibition registration) Workshop Presentation During the few last years, the Linux operating system has progressively positioned as a strong alternative to proprietary and/or commercial solutions in embedded systems, whether it is deeply embedded or not, and this for many application domains, such as multimedia, telephony, transports, automotive … The purpose of this workshop is to present research projects, experimentations, significant and original realizations that lie upon the implementation of an embedded Linux</pre> John Williams 2012-02-24T00:04:10 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11716 <pre>This tiny patch adds generic atomic64 support for the Microblaze architecture. The patch is against the latest linux-2.6-microblaze tree. It also fixes the kernel build for microblaze: CC kernel/trace/trace_clock.o kernel/trace/trace_clock.c:117: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'trace_counter' kernel/trace/trace_clock.c: In function 'trace_clock_counter': kernel/trace/trace_clock.c:126: error: implicit declaration of function 'atomic64_add_return' kernel/trace/trace_clock.c:126: error: 'trace_counter' undeclared (first use in this function) kernel/trace/trace_clock.c:126: error: (Each undeclared identifier is reported only once kernel/trace/trace_clock.c:126: error: for each function it appears in.) make[2]: *** [kernel/trace/trace_clock.o] Error 1 make[1]: *** [kernel/trace] Error 2 make: *** [kernel] Error 2 Signed-off-by: Ariane Keller &lt;ariane.keller-/S6NX+md4ZWVRmA6MYkXiA&lt; at &gt;public.gmane.org&gt; Signed-off-by: Daniel Borkmann &lt;daniel.borkmann-/S6NX+md4ZWVRm</pre> danborkmann-FeC+5ew28dpmcu3hnIyYJQ< at >public.gmane.org 2012-01-18T13:25:26 http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11683 <pre> **************************************************************************** *************** Call For Papers The 2nd Embed With Linux (EWiLi) Workshop Submission deadline: 4 March 2012 7 June 2012, Cité de la voile, Lorient, France **************************************************************************** *************** Workshop Presentation During the few last years, the Linux operating system has progressively positioned as a strong alternative to proprietary and/or commercial solutions in embedded systems, whether it is deeply embedded or not, and this for many application domains, such as multimedia, telephony, transports, automotive … The purpose of this workshop is to present research projects, experimentations, significant and original realizations that lie upon the implementation of an embedded Linux operating system both in academic and industrial worlds. The workshop objective is also to be a meeting place for industrial and academic actors. Expected contribut</pre> Jalil Boukhobza 2011-12-14T10:29:33 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.uclinux.microblaze