Re: [PATCH 1/2] powerpc: export ppc_tb_freq so that modules can reference it
Hi Scott, On Sat, 18 Sep 2010 14:22:12 -0400 Josh Boyer jwbo...@gmail.com wrote: Capitalizing? The patch you posted that uses this symbol is for a GPL driver so you gain or lose nothing by having this symbol be EXPORT_SYMBOL_GPL. Are you somehow advocating and getting some sort of gain by allowing non-GPL modules? If so, I find that unfortunate. If not, then I guess I don't understand what you mean by capitalizing. One can dislike DRM (even a very weak form such as this) without having a particular desire to go outside the bounds of what it allows. I thought EXPORT_SYMBOL_GPL was originally meant to indicate the symbols whose use is likely to be indicitave of code that is, in some copyright-meaningful way, derived from GPL code? Google finds this, which coincides with what I remmber[1]: EXPORT_SYMBOL_GPL Some kernel developers are unhappy with providing external interfaces to their code, only to see those interfaces being used by binary only modules. They view it as their work being appropriated. Whether you agree with that view or not is completely irrelevant, the person who owns the copyright decides how their work can be used. EXPORT_SYMBOL_GPL() allows for new interfaces to be marked as only available to modules with a GPL compatible license. This is independent of the kernel tainting, but obviously takes advantage of MODULE_LICENSE() strings. EXPORT_SYMBOL_GPL() may only be used for new exported symbols, Linus has spoken. I believe the phrase involved killer penguins with chainsaws for anybody who changed existing exported interfaces. Cheers Detlev [1] http://lkml.indiana.edu/hypermail/linux/kernel/0110.2/0369.html -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problems using UART on MPC5200
Hi Sven, I am using a PowerPC MPC5200 from Freescale (with STK5200-Board), ELDK 4.2 from DENX and the Kernel 2.6.34-rc5. My Kernel is running fine. The console output is coming over the device ttyPSC0. In future I want to login over telnet. So I deactivated the Kerneloption to output the console over the UART device. It would help if you were more precise in describing what you did and what you try to achieve. What exact option did you change? Now I want to read and write to the RS232 interface from a program. But when I try to open the device ttyPSC* I get the following error: unable to read portsettings : Inappropriate ioctl for device The message means what it says - whatever device driver is connected to the device file you open does not support the ioctl you call on it. Now to better understand this, it would help if you tell us what device file you open, what major and minor number this has, what /proc/devices shows this hooks to and what ioctl you do in your application. What does this mean ? How can I send and receive Data from/to the UART ? This should all work with standard procedures. Cheers Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cross-compiling Linux for PowerPC e200 core?
Hi Segher, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=33d9e9b There is no obvious way to get there via clicking afaics, the commit search box doesn't work at least. Hrm. It works, but not like one would expect, i.e. check out the help: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=search_help Last I checked the gitweb code, there was no easy way other than what you did by manipulating the URL directly. Cheers Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][POWERPC] WDT: added support for the WDT Chain driver.
Hello Vitaly, From: Heiko Schocher h...@denx.de [POWERPC] WDT: added support for the WDT Chain driver. This new driver implements a character device with major number 10 and minor number 130. It is a software abstraction of the hardware watchdog with two different APIs. While the driver periodically triggers the hardware watchdog, the software can setup independent timeout periods. More info in Documentation/watchdog/wdt_chain.txt Signed-off-by: Heiko Schocher h...@denx.de Signed-off-by: Vitaly Bordug v...@kernel.crashing.org --- This code was (and is) originally residing in DENX public git repo. I think it would be useful upstream, to prevent reinventing the same thing. Thanks a lot for taking an interest in this piece of code. I would suggest however that you coordinate with Heiko as he has worked some more on this driver in the meantime. This new code however is not in our repository. We should start the RFC discussion with current code. For the casual reader this means, don't invest time into reviewing this but wait for a cleaned up version instead. Thanks Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 832x: MATH_EMUL
Hi Kumar, On Aug 21, 2009, at 1:39 AM, Heiko Schocher wrote: Hello, I actually porting a mpc8321 based port, and because there is no FPU on this CPU, I activated MATH_EMUL, as all other mpc832x ports did. Is there something like a counter, which counts how many times this Exception occurs? Geert published some patches that did something like this but there isn't upstream as far as I know at this point. Were there any technical reasons or did it just slip into the cracks? In my opinion such a counter would be *very* helpful to judge the performance impact one suffers instead of living in ignorant bliss. Cheers Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ethernet phy attached to wrong driver
Hi Stefan, I'm having trouble with my Ethernet device on a TQM5200 based board with LXT971 Phy. I'm running U-Boot 2009.03 and a Kernel 2.6.30. When doing a ping under U-Boot before booting into Linux, Ethernet works fine in Linux also. Dmesg reads: [ 262.369444] net eth0: Using PHY at MDIO address 0 [ 263.265903] net eth0: attached phy 0 to driver LXT971 But if I start Linux without prior use of the fec under U-Boot, Ethernet is not working in Linux. The wrong drivers seems to be attached to the phy. Dmesg reads: [2.068285] net eth0: Using PHY at MDIO address 0 [2.964774] net eth0: attached phy 0 to driver Generic PHY ^^^ Is there a bootarg to tell linux which driver to use? Any ideas what I'm doing wrong? I cannot reproduce this problem with a tqm5200/stk52xx combination. Linux always happily uses a genric PHY, irrelevant if I use networking in U-Boot. Cheers Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc52xx_uart.c - Port Overruns
Hi Damien,
I am writing to ask about some particular behaviour we saw with the MPC5121
PSC
UART, using the 2.6.24 Freescle BSP kernel, although examining the code of the
linux-2.6-denx tree (git commit 7cb16ec2590815a67e5fb5c8994ead536613d922), the
behavior is almost identical except for incrementing an overrrun counter.
In particular, yesterday we observed a port overrun (from the overrun flags
being set when looking with the BDI) on one of our PSC Ports. When it was
observed, we saw that every second byte coming from the serial port was 0x00.
Examining the interrupt routine of the mpc52xx_uart.c:
static inline int
mpc52xx_uart_int_rx_chars(struct uart_port *port)
{
snip
tty_insert_flip_char(tty, ch, flag);
if (status MPC52xx_PSC_SR_OE) {
/*
* Overrun is special, since it's
* reported immediately, and doesn't
* affect the current character
*/
tty_insert_flip_char(tty, 0, TTY_OVERRUN);
port-icount.overrun++;
}
snip
}
So, from my deduction, it is inserting a 0x00 for every overrun error that
occurs, however, the overrun flag is never cleared. Therefore fro every byte
that is received, the overrup flag is still set and therefore we're observing
the 0x00 being inserted for every real byte coming into the port
Is there a particular reason why the overrun flag is not cleared? That is,
parity, framing and breaks are acknowledged with:
/* Clear error condition */
out_8(PSC(port)-command, MPC52xx_PSC_RST_ERR_STAT);
But the overrun isn't cleared. Is there are particular reason why? Is
userspace meant to detect this condition and reset the port? Was it
automatically cleared on the 5200 when reading the status, but the 5121 is
exhibiting strange behavior?
This is likely only forgotten in the driver. I remember fixing this in
our 2.4 kernel tree a long time ago[1].
Cheers
Detlev
[1]
http://git.denx.de/?p=linuxppc_2_4_devel.git;a=commitdiff;h=00097a16641865b88568b807c9680b50c74bda84
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc405ex + gigabit ethernet
Hi Lada, Hi, I benchmarked performance of my network, which contains ppc405EX (Kilauea board, kernel 2.6.30 from Denx) connected with a linux desktop via gigabit ethernet. I used the netperf tool: netperf -t UDP_STREAM -H 192.168.1.1 -- -m 32768 So I was sending UDP packets to the desktop. The resulting speed was about 370 Kb/s. I tried to send the packets to several different computers - with the same result. So the ppc board is the bottleneck in this case. Is there any possibility to improve the gigabit capabilities of the ppc405EX? Is there anyone who achieved a better performance with ppc4xx boards? On our kilauea in the lab: -bash-3.2# src/netperf -t UDP_STREAM -p 7776 -H 192.168.1.1 -fK -- -m 32768 UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.1 (192.168.1.1) port 0 AF_INET Socket Message Elapsed Messages SizeSize Time Okay Errors Throughput bytes bytessecs# # KBytes/sec 106496 32768 10.003601 011519.64 124928 10.003601 11519.64 -bash-3.2# grep cpu /proc/cpuinfo cpu : 405EX -bash-3.2# cat /proc/version Linux version 2.6.29.4 (d...@pollux.denx.de) (gcc version 4.2.2) #9 Wed Jun 17 11:18:46 CEST 2009 -bash-3.2# I can send you the kernel+dtb that I used for testing offlist. Cheers Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Trouble Transferring control to Linux (at address 00000000)
Hi, As for my device tree, I reverted back to the original version with nothing filled in and just replaced 0xfa20 with 0xf000 as Gary suggested earlier. Would it be a problem to also dynamically fixup IMMR in the device tree from U-Boot? Cheers Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with radeonfb on PowerPC 7448MV64560
Hi Eduard, Am Mittwoch 18 März 2009 00:05:00 schrieb Benjamin Herrenschmidt: On Tue, 2009-03-17 at 16:30 +0100, Eduard Fuchs wrote: Hi all, since several days I'm trying to run an ATI 9250 (PCI) graphic card under Linux Kernel 2.6.27.19. Nevertheless without success. The kernel shows the following message: videoboot: Booting PCI video card bus 0, function 0, device 7 biosEmu: undefined interrupt 15h called! biosEmu/bios.int42: unknown function AH=0x0, AL=0x7, BL=0x0 The above comes from some patches you added to the kernel ? You should probably do the softboot in the firmware instead... Yes. I'm using the videoboot-2.6x.patch (this patch contain also the xf86emu from www.scitechsoft.com). With this pach the radeon card work properly with 2.6.12 kernel version. On the 2.6.27 kernel the videoboot fetch the bios from the video card and start them in the xf86emu. Can I initialize the video card in uboot too? Yes, indeed you can. In a recent version of U-Boot, search for 'CONFIG_BIOSEMU' in include/configs/*. We tested this on a sequoia board, so include/configs/sequoia.h should be a good start for this. Cheers Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: jffs2 and unaligned access
Hi, memcpy_from/to_io() use word aligned accesses on the io side of memory. The MPC5200 local plus bus where our flashes are connected does not allow unaligned accesses, so we have to use the io versions of memcpy. But this region of flash is marked as suitable for execute-in-place, otherwise the point() function wouldn't be working to give a direct pointer to it. It sounds like we shouldn't be allowing that. Which in turn means that perhaps we should have a property in the corresponding node in the device-tree which indicates that it's not suitable for direct access? This isn't usually a property of the flash device, but of the various buses/controllers above the flash device. I wholeheartedly agree. After all, its the Local+ bus playing games here. And fixing that for JFFS2 only ignores that other devices can *and will* be connected on this bus. Unaligned accesses to such devices will also fail (likely from mtd unrelated code) - and fail silently, taking quite a while to figure out what is going wrong where. The device tree should mimic reality (and it does, it just seems the kernel doesn't use this information yet?) How is this exactly supposed to work? Cheers Detlev -- In the topologic hell the beer is packed in Klein's bottles. -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: All your drivers are belong to us
Hi, On Wed, 7 May 2008 17:42:51 -0400 Sean MacLennan [EMAIL PROTECTED] wrote: On Wed, 07 May 2008 16:36:30 +0200 Detlev Zundel [EMAIL PROTECTED] wrote: It also happened that a driver once posted for what the customer thought was a completely specific device of his own today supports lots of different boards from at least four different manufacturers. The wording is of course not exact but I hope I caught the spirit of what Greg wanted to say. So yes, please post the driver - maybe Greg KH will tunnel it into mainline... I agree with the sentiment. However, it is hard enough to get legitimate drivers into the kernel. The drivers I mentioned do not come close to following the Linux kernel coding spec. Here's the cool part. There's this Linux driver project: http://www.linuxdriverproject.org/twiki/bin/view where they can take drivers like that and clean them up. At least to a reasonable degree. The benefit for you is that once it's cleaned up, it can go into the mainline kernel and it will just be there in future releases. Helpful when you update. Yes, I should have mentioned this also in my original mail. If I remember correctly, Greg mentioned that in this project, he has *300* developers waiting to do something. None of the companies previously claiming Linux had a driver problem showed up even when he contacted them directly Now, I can't say I've personally ever used that project but its mission does seem pretty targeted towards groups that want to do the right thing with respect to drivers. Maybe you could give it a shot and tell others about the experience. This would definitely be interesting. Cheers Detlev -- -- Question authority! -- Yeah, says who? -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
All your drivers are belong to us [was WARNING: mutexes are preferred for single holder semaphores]
Hi Sean, The code is GPLed but not currently available on the net. It is basically a little driver that registers a character device and then passes out the minor numbers to the PIKA board drivers. It was written to isolate all the character/sysfs code to one place since we have five drivers, and many debug drivers, that use it. If anybody is really interested, I can post it here. I doubt it will ever be submitted to the mainline kernel however. Just for the record and because it may be interesting to others, during the Hannover Messe end of April, in the context of the OSADL Congress[1] I attended a speech of Greg KH about driver development and citing from memory he said: I am serious, please post all drivers that there are, even if you think they are useless for other people. We have a driver in mainline for a device that I know only exists once in the whole world. Having the drivers in the kernel gives the developers the chance to see how the infrastructure is being used and to isolate good opportunities for modularization benefiting the linux kernel. [...] It also happened that a driver once posted for what the customer thought was a completely specific device of his own today supports lots of different boards from at least four different manufacturers. The wording is of course not exact but I hope I caught the spirit of what Greg wanted to say. So yes, please post the driver - maybe Greg KH will tunnel it into mainline... Cheers Detlev [1] http://www.osadl.org/International-Congress-Open-Source-mee.hannover-2008-congress.0.html PS: The OSADL pages should be updated in a few days to link to slides of the talks. -- Ftpd never switches uid and euid, it uses setfsuid(2) instead. The main reason is that uid switching has been exploited in several breakins, but the sheer ugliness of uid switching counts too. -- pure-ftpd(8) -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Signal backtrace function
Hi Jocke, On Mon, 2008-04-14 at 18:09 +0200, Detlev Zundel wrote: Hi Jocke, I made my own backtrace function for printing a trace from within a signal handler. Maybe it can be useful for the kernel too? General comments welcome. Probably a dumb question, but doesn't backtrace(3) from glibc work architecture independent already? Why do you need to reimplement it? Nope, it doesn't give you a good backtrace from within a signal handler. On x86 you can use the normal backtrace function with a minor workaround, but as ppc doesn't save a FP in leaf functions, that workaround does not work well. You can read more about it at http://www.linuxjournal.com/article/6391 Thanks for clearing that up. I wasn't aware of that limitation. Cheers Detlev -- In short: much of our country's [USA] counterterrorism security spending is not designed to protect us from the terrorists, but instead to protect our public officials from criticism when another attack occurs. -- Bruce Schneier -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Signal backtrace function
Hi Jocke, I made my own backtrace function for printing a trace from within a signal handler. Maybe it can be useful for the kernel too? General comments welcome. Probably a dumb question, but doesn't backtrace(3) from glibc work architecture independent already? Why do you need to reimplement it? Thanks Detlev -- The management question ... is not _whether_ to build a pilot system and throw it away. You _will_ do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. - Fred Brooks, The Mythical Man Month -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: jffs2 file system on MPC8272ADS board
Hi Nethra, The other options I am wondering about, -c, --cleanmarker=SIZE Size of cleanmarker (default 12) -n, --no-cleanmarkers Don't add a cleanmarker to every eraseblock cleanmaker size will it help the cause? Skimming through the thread I cannot tell whether you use NAND or NOR, but on NAND flash, the cleanmarkers are actually in the out-of-band area and thus *should not* be in the image, so for NAND we need the -n option. I don't think you should have to adjust the size, at least I never needed this. Best wishes Detlev -- I've been examining the existing [linux] kernel configuration system, and I have about concluded that the best favor we could do everybody involved with it is to take it out behind the barn and shoot it through the head. -- Eric S. Raymond on linux-kbuild Mar 2000 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
