Re: uboot parsing
Dear Ajit Phadnis, In message caknr0cilk3bfgwzuwes1khqecan6q5bpj2psn6gnmbtobcs...@mail.gmail.com you wrote: Would like to how to store the response command of a run command You should ask U-Boot related questions on the U-Boot mailing list [1] instead; chances for a helpful reply are much better there than on lists that do not actually deal with U-Boot. Would to store the outcome of run addr in into a variable and grep for the characters or string in Uboot. Unfortunately, there is currently no way (yet) to do that. When the hush shell was ported to U-Boot, it was configured and modified for minimal memory footprint; one of the features that have not been included is command substitution. If you really need such a feature, you could port (or have ported) a more recent version of hush and include this feature. Today's systems usually have much more resources than we had at the time when hush was added, so the additional memory footprint should be acceptable (especially if you make that option configurable, so those who are not interested in it or are already tight on memory can opt out). Further discussions should be done on the U-Boot list [1]. [1] http://lists.denx.de/mailman/listinfo/u-boot Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In an organization, each person rises to the level of his own incom- petency - The Peter Principle ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Regarding storing and parsing in Uboot
Dear Kiran, arghhh... Please do not post the same question in several messages to many addrresses; if you really feel you need to send it to all, then please put all on Cc: so all can receive the replies, too. I answered before: In message CAPbBx=45O4UrKLoVjCvg5wEnTab-dGo=-o5sh6owgd49cq6...@mail.gmail.com you wrote: In uboot, i run some IPMI commands and I have to store that value in uboot and also extract the interim byte of the output value. I'm afraid we cannot help you with that. We know only the mainline code of U-Boot, and this does not include any kind of IPMI support. Apparently you are using some vendor version with specific extensions. Without knowing this code it is impossible for us to help you, sorry. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [POWERPC] 4xx: EP405 boards support for arch/powerpc
Dear Ben, In message 1413802359.18300.7.camel@pasglop you wrote: Ah, I even forgot I wrote that ... I'll have to dig out the docs of that chip, maybe later this week. Thanks ! ... 565 cbdv = ((pllmr 0x0006) 17) + 1; /* CPU:PLB */ 566 opdv = ((pllmr 0x00018000) 15) + 1; /* PLB:OPB */ 567 ppdv = ((pllmr 0x1800) 13) + 1; /* PLB:PCI */ ^ This mask and shift means that ppdv is always 1. See 7.7.1 PLL Mode Register (CPC0_PLLMR) page 7.10f: Bits 17:18 PPDV PCIPLB Frequency Divisor So that should be (... 0x6000) 13 ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Only in our dreams we are free. The rest of the time we need wages. - Terry Pratchett, _Wyrd Sisters_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] watchdog: mpc8xxx_wdt: MPC8xx is HW enabled
Dear Guenter, In message 529b9152.9090...@roeck-us.net you wrote: On 11/30/2013 07:45 AM, Christophe Leroy wrote: MPC8xx watchdog is enabled at startup by HW. If the bootloader disables it, it cannot be reenabled. Is that true for all variants of 8xx, especially for 823 ? I am a bit concerned about breaking compatibility with some chips ... assuming there was a reason for not setting this flag originally. This is correct, and applies for all variants of the MPC8xx, including the MPC823 / MPC823E. From the UM: The software watchdog timer can be disabled or its timeout period can be changed in the SYPCR. Once the SYPCR is written, it cannot be written again until a system reset. Actually this is the only correct behaviour. Any watchdog that can be disabled by software is not worth it's name, and unsuitable for any kind of aplications where security / reliability are required. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Ninety-Ninety Rule of Project Schedules: The first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Emulate lwsync to run standard user land on e500 cores
Dear Kumar, In message 6bfc8eb0-1a75-41c3-985a-e3ed14846...@kernel.crashing.org you wrote: Fair enough I'm not too worried as long as we warn and account them. Than, I'd ask this be under a Kconfig option that is disabled by default. Users should have to explicitly enable this so they know what they are doing. Is this really worth the effort? Under normal situations (users are using a user space environment that has been properly buiult for the processor variant they are using) nobody should ever run into this situation. It happens only if you are already doing something wrong - like using user space that has not been built for an E500 core on such a machine. In this situation, it seems more useful to me if a standard kernel just works with a standard user space environment, even if this includes some performance penalty - which actually should be neglibale. In my tests (when running standard Debian for PPC on a E500 only very few programs actually triggered this situation, and none of them in a time-critical way. I doubt I would even be able to measure the performance impact. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ...all the good computer designs are bootlegged; the formally planned products, if they are built at all, are dogs! - David E. Lundstrom, A Few Good Men From Univac, MIT Press, 1987 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Emulate lwsync to run standard user land on e500 cores
Dear Scott, In message 1382697373.3926.36.ca...@aoeu.buserror.net you wrote: Has anyone measured how much this slows things down with a typical userspace? In the applications I found to trigger this issue the number of traps is so small that I can't even reliably measure any difference. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When it is incorrect, it is, at least *authoritatively* incorrect. - Hitchiker's Guide To The Galaxy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [RFC] Emulate lwsync to run standard user land on e500 cores
Default Debian PowerPC doesn't work on e500 because the code contains
lwsync instructions, which are unsupported on this core. As a
result, applications using this will crash with an unhandled signal 4
Illegal instruction error.
As a work around we add code to emulate this insn. This is expensive
performance-wise, but allows to run standard user land code.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Scott Wood scottw...@freescale.com
---
I am aware that the clean solution to the problem is to build user
space with compiler options that match the target architecture.
However, sometimes this is just too much effort.
Also, of course the performance of such an emulation sucks. But the
the occurrence of such instructions is so rare that no significant
slowdown can be oserved.
I'm not sure if this should / could go into mainline. I'm posting it
primarily so it can be found should anybody else need this.
- wd
arch/powerpc/kernel/traps.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index f783c93..f330374 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -986,6 +986,13 @@ static int emulate_instruction(struct pt_regs *regs)
return 0;
}
+ /* Emulating the lwsync insn as a sync insn */
+ if (instword == PPC_INST_LWSYNC) {
+ PPC_WARN_EMULATED(lwsync, regs);
+ asm volatile(sync : : : memory);
+ return 0;
+ }
+
/* Emulate the mcrxr insn. */
if ((instword PPC_INST_MCRXR_MASK) == PPC_INST_MCRXR) {
int shift = (instword 21) 0x1c;
--
1.8.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Emulate lwsync to run standard user land on e500 cores
Dear Scott, In message 1382114321.7979.840.ca...@snotra.buserror.net you wrote: There's already been a patch posted for this: http://patchwork.ozlabs.org/patch/256747/ I plan to apply it for my next pull request. Ah, cool. Thanks! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is better to have tried and failed than to have failed to try, but the result's the same. - Mike Dennison ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure to detect PCI card
Dear Peter LaDow, In message can8q1ed-ytd1l7e9tajyeldcz5rcfdi0mdwu_h6hax0-3fj...@mail.gmail.com you wrote: I have a PCI card (a Netgear FA331, vendor:device 100b:0020) that is failing to be detected by our PPC platform. This device works just fine in a PC, and other cards work just fine in the same PCI slot (we have an Intel 82540EM based card that works). But for some reason, neither u-boot nor the kernel detect this card. Any ideas why this might be? Is there any chance that this card has some BIOS (like most graphic adapters do) which needs to run to put the card into an operative state (like by initializing any DRAM memory on the card)? OK, I would normally not expect such on a 10/100 PCI Ethernet network adapter, but I don't know this card at all... Do you know if this card works in any other non-x86 system at all? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Quote from a recent meeting: We are going to continue having these meetings everyday until I find out why no work is getting done. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MSR loses DE bit in 3.3, BDI2000 cant handle breakpoints?
Dear Bob, In message 4fc511c1.4050...@mindchasers.com you wrote: I debug using Freescale CodeWarrior and a USB tap, which also rely on MSR[DE] being set. I develop from the mainline have a patch set that I just recently re-tweaked to support kernel debugging. If you want, I'll send you my set of patches for the kernel. They might be useful (not sure since I don't use BDI). Please rather submit as a patch on the mailing list. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de egrep patterns are full regular expressions; it uses a fast determi- nistic algorithm that sometimes needs exponential space. - unix manuals ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v16 01/10]USB/ppc4xx: Add Synopsys DWC OTG Register definitions
Dear Rupjyoti Sarmah, In message 201205031223.q43cn3ln022...@amcc.com you wrote: Add Synopsys Design Ware core register definitions. Olof Johansson o...@lixom.net has commented v15 of this patch as follows: No, just start over from scratch. Just leave the crap driver behind, use it for reference but write the new one. It's obvious given that you are already at iteration v15 and it's still looking this bad that this is not realistic to get reviewed and accepted as-is. I don't think staging is a good target either -- what the driver really needs is _functional_ cut-down to only cover the use cases that your product uses, and staging cleanups are mostly around style and refactoring, not changing, fixing or removing functionality. ... I don't think you understood what I meant. Try building an ARM config with this driver enabled, for example, and you'll see that it breaks the build. See http://thread.gmane.org/gmane.linux.usb.general/53348/focus=53913 for the full context and other important comments. It seems most of these requests have been ignored so far. I would also like to point out that the same Synopsys USB controller is used in a number of other SoCs (especially ARM chips), and supported by other drivers, some of these even in mainline. See http://thread.gmane.org/gmane.linux.usb.general/61714/focus=62139 for a related thread. Instead of trying to add a completely new driver to mainline (and one which has been repeatedly been rejected), I vote for focussing on the existing driver code that is already in mainline, and testing and improving this so we can use a single implementation of this driver code for all SoCs that use the same IP block. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de panic: kernel trap (ignored) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
Dear Stephen Rothwell, In message 20120405100228.9ca940aa4739e81540bb2...@canb.auug.org.au you wrote: ELDK 4.2 is based on gcc version 4.2.2 / binutils version 2.17.50.0.12 20070128. This is obviously to old for this code. I do not see an actual problem with that - nobody can expect that we support old tol chain versions forever. The requirements are documented in Documentation/Changes where we say we need gcc 3.2 and binutils 2.12. Not that that is very relevant to this discussion. ;-) Indeed. I doubt you can build any working PPC kernel with these old tools. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Consistency requires you to be as ignorant today as you were a year ago. - Bernard Berenson ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2
Dear Josh, In message CA+5PVA6jQgme0sS=i8yyx6b_r5179+btwph7qxcgnfoltct...@mail.gmail.com you wrote: The kernel shouldn't have tried to build that instruction on 8xx, though I suppose if it's in arch/powerpc/boot, we are a bit too eager at building everything including what's not relevant, we might to be a bit more careful at excluding 4xx stuff on a 8xx kernel. It's still a binutils issue. Sounds like the toolchain being used to build the 8xx kernel is specifically built for 8xx. A generally built binutils should have worked fine (assuming it was new enough), since we pass -mcpu=405. The problem is the assuming it was new enough part. The kernel README says nothing about binutils requirements, the only tool related statement is Make sure you have at least gcc 3.2 available. Actually I doubt if gcc 3.2 wouldbuild a working kernel image. ELDK 4.2 is based on gcc version 4.2.2 / binutils version 2.17.50.0.12 20070128. This is obviously to old for this code. I do not see an actual problem with that - nobody can expect that we support old tol chain versions forever. But then, I think if we make assumptions about tool versions, we should add appropriate tests and issue helpful error messages. Here, we should issue an error binutils versions x.y.z or later needed or similar. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have made mistakes, but have never made the mistake of claiming I never made one. - James G. Bennet ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
Dear Mai La, In message 1331524918-22515-1-git-send-email-...@apm.com you wrote: This patch consists of: - Enable PCI MSI as default for Bluestone board - Change definition of number of MSI interrupt as it depends on SoC - Fix returning ENODEV as finding MSI node - Fix MSI physical high and low address - Keep MSI data logically Signed-off-by: Mai La m...@apm.com This is an updated version of your patch of March 09, right - http://article.gmane.org/gmane.linux.kernel/1264255 ?? If so, you should mark ot as patch V2 in the Subject:, and add a description of what you changed. - SDR0_WRITE(sdr_addr, (u64)res.start 32); /*HIGH addr */ - SDR0_WRITE(sdr_addr + 1, res.start 0x); /* Low addr */ - + mtdcri(SDR0, *sdr_addr, upper_32_bits(res.start)); /*HIGH addr */ + mtdcri(SDR0, *sdr_addr + 1, lower_32_bits(res.start)); /* Low addr */ ... + msi-msi_addr_hi = (u32)(msi_phys 32); + msi-msi_addr_lo = (u32)(msi_phys 0x); Is there any reason for not using upper_32_bits() / lower_32_bits() consistently? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Real computer scientists despise the idea of actual hardware. Hard- ware has limitations, software doesn't. It's a real shame that Turing machines are so poor at I/O. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mac address in the DT
Dear smitha.va...@wipro.com, In message 40631e9a2581f14ba60888c87a76a1fe01d...@hyd-mkd-mbx4.wipro.com you wrote: The fdt_fixup_ethernet() is not supported in the older version of u-boot. So how to go about it in u-boot 1.3.0 version. U-Boot v1.3.0 is more than 4 years old. Update, or restrict yourself to using 4 years old Linux kernel versions as well, like v2.6.23 or so :-( Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Everyting looks interesting until you do it. Then you find it's just another job. - Terry Pratchett, _Moving Pictures_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mac address in the DT
Dear smitha.va...@wipro.com, In message 40631e9a2581f14ba60888c87a76a1fe01d...@hyd-mkd-mbx4.wipro.com you wrote: Setenv set_mac 'cp 0xffec 0x10 1024;fdt addr 0xc0 8192;fdt set= /soc8272@f000/ethernet@24000 mac-address [00 44 00 55 00 66];erase 0x= ffec 0xffec4000;cp 0xc0 0xffec 1024;bootm 0xfe06 - 0xffec000= 0' run set_mac For the above command I want to replace the mac address with the ethaddr How do I do that. I tried $ethaddr but I get extra : characters. Why would you do that at all? U-Boot will run fdt_fixup_ethernet() for all (at least AFAICT) supported architectures, which will replace mac-address and local-mac-address for all ethernet? interfaces in the device tree for which a corresponding ethadd / eth?addr environment variable is set. No additional actions are needed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de One day, said a dull voice from down below, I'm going to be back in form again and you're going to be very sorry you said that. For a very long time. I might even go so far as to make even more Time just for you to be sorry in. - Terry Pratchett, _Small Gods_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mac address in the DTS file
Dear smitha.va...@wipro.com, In message 40631e9a2581f14ba60888c87a76a1fe01c...@hyd-mkd-mbx4.wipro.com you wrote: In my DTS file for mpc8247 I have defined the ether MAC in the node as below. On a MPC82xx there is a chance that you are using U-Boot as boot loader... How do I change the MAC address. If different targets boards are U-Boot can store (it the environment variables) MAC addresses and update the DT with this information. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux tqm8260
Dear bourkeb idir, In message 1309510675.9518.yahoomail...@web29503.mail.ird.yahoo.com you wrote: i'm trying to port linux in a tqm8260 fresscale card with an mpc8260 cpu .i've already ported u-boot and it seems working but now i'm trying to cross compile a linux kernel 2.4.4 (which have a config file for tqm8260) and i always get trouble when i try to make a zImage . can anyone help me ,please? This statement makes little sense to me. First, the TQM8260 is not a Freescare card. The manufacturer is (or rather was) TQ Systems. Second, I wonder why you would spend any efforts into such a system - the product was EOLed a long time ago. Third, when the product was still alive, it was pretty well supported by U-Boot and Linux. U-Boot sopport for it is still available in mainline. Linux support was available in our linuxppc_2_4_devel tree up to and including Linux version 2.4.25. So using 2.4.4 as a starting point for such a work is even more incomprehensible to me. If you really have a TQM8260 board, then just use the mainline U-Boot code (current release, i. e. v20100.06) and the old 2.4.25 based source tree mentioned above. But be warned: this is ancient hardware, and so is the kernel code. There is no guarantee it will even compile using recent tool chains. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You've no idea of what a poor opinion I have of myself, and how little I deserve it. - W. S. Gilbert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core Interface Layer (CIL)
Dear tma...@apm.com, In message 1301684711-17386-1-git-send-email-tma...@apm.com you wrote: From: Tirumala Marri tma...@apm.com Core Interface Layer Common provides common functions for both host controller and peripheral controller. CIL manages the memory map for the core. It also handles basic tasks like reading/writing the registers and data FIFOs in the controller. CIL performs basic services that are not specific to either the host or device modes of operation. These services include management of the OTG Host Negotiation Protocol (HNP) and Session Request Protocol (SRP). --- Signed-off-by: line missing. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de No problem is so formidable that you can't walk away from it. - C. Schulz ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Need help for USB OTG feature for Canyonlands PPC460EX Board
Dear sunny bhayani, In message AANLkTikatrqNZydG3Do8UgYeB4c=iteBG==r2dbn6...@mail.gmail.com you wrote: I am trying to enable the USB DWC OTG feature for Canyonlands PPC460EX Board, and am using the 2.6.30 kernel from denx. Now the issue is I am selecting the USB Gadget feature from the kernel menuconfig, but the kernel log only shows, I don't really understand why you ask this again, now on the next mailing list - after I sent you a reply on the ELDK list. Here is a link to my reply: http://thread.gmane.org/gmane.comp.embedded.eldk/1827/focus=1828 Please update, and try again. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de grep me no patterns and I'll tell you no lines. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc880 linux-2.6.32 slow running processes
Dear Rafael Beims, In message aanlktin5xtndeu1bjuoef0uwtfepotw5bq__i8g6u...@mail.gmail.com you wrote: I'm working with an MPC880 board that is supposed to run linux-2.6.32. After some work, I could get the kernel up and running, mounting a rootfs via NFS. 2.6.32 is pretty old. Is there any specific reason for not using a recent kernel version? The problem that I'm facing now is that when I try to run any process (may be an ls, cat, or whatever), the response of the process is *very* slow (something like 10 to 20 seconds for a ls). This sounds as if only the output to the (serial ?) console port was slow - typically this happens when there is a problem with interrupt assignment, and you receive charatcers only after each of these times out. My question to all is, did anyone see something like this already? Besides We have seen this many times in the past, when interrupts were not working correctly. I recommend to check youyr device tree settings for these. [It would have helped if you had included a log of your kernel's boot messages.] that, what is the status of the linux kernel support for the 8xx platform? It is working and actively maintained, but 8xx is a platform that is more or less hopelessly obsoleted - nobody uses it in new designs any more, so there is little work going on with it in recent kernel versions (at least compared with other architectures). Is it being actively tested / used today? I ask this because it seems that Yes, it is. all the information on the internet very aged (forum discussions from 2005 and below mostly). Is there something that I can do to try to narrow the cause of the problem? Check your interrupts. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Never underestimate the power of human stupidity when it comes to using technology they don't understand. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with MPC5121 custom board.
Dear =?iso-8859-1?Q?CTAG_/_Mois=E9s_Dom=EDnguez?=, In message 765b188b547a48e7951d86acc3544...@ctag you wrote: We have a problem with custom design based on ads5121. May be you could provide us any clue about what may be happening. Sometimes, when the board is powered-on: - U-boot does not start (at least serial port does not output anything, I don't know if some piece of u-boot is executed). In an overwhelming majority of such cases this is an indication of incorrect and/or incomplete initialization of your system RAM. See the FAQ at http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation Note that U-Boot related questions (and this is one) should better go to the U-Boot mailing list instead (see http://lists.denx.de/mailman/listinfo/u-boot) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can only live once, but if you do it right, once is enough. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] ppc44x:PHY fixup for USB on canyonlands board
Dear Rupjyoti Sarmah,
In message 201011261110.oaqbanzl012...@amcc.com you wrote:
+ c...@2,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = apm,ppc460ex-bcsr;
This results in a mix of amcc, and apm, strings.
Are there any plans to unify this?
diff --git a/arch/powerpc/platforms/44x/canyonlands.c
b/arch/powerpc/platforms/44x/canyonlands.c
new file mode 100644
index 000..61e80ce
--- /dev/null
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -0,0 +1,120 @@
+/*
+ * This contain platform specific code for Canyonlands board based on
+ * APM ppc44x series of processors.
Canyonlands is always PPC460EX, or does it ever come with other
processors as well?
+static int __init ppc44x_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+ if (of_flat_dt_is_compatible(root, amcc,canyonlands)) {
+ ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC);
+ return 1;
+ }
+ return 0;
+}
Bad indentation.
+ /* Disable USB, through the BCSR7 bits */
+ setbits8(bcsr[7], BCSR_USB_EN);
+
+ /* Wait for a while after reset */
+ msleep(100);
+
+ /* Enable USB here */
+ clrbits8(bcsr[7], BCSR_USB_EN);
+
+ /*
+ * Configure multiplexed gpio16 and gpio19 as alternate1 output
+ * source after USB reset.This configuration is done through GPIO0_TSRH
+ * and GPIO0_OSRH bits 0:1 and 6:7.
+ */
Earlier versions of the patch included a delay after the clrbits8()
call as well. Is it intentional that you dropped this now?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Every program has at least one bug and can be shortened by at least
one instruction - from which, by induction, one can deduce that every
program can be reduced to one instruction which doesn't work.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [REPOST] [PATCH 0/6] fixes and MPC8308 support for the mpc512x_dma driver
Dear Ilya Yanok, In message 1288137180-3220-1-git-send-email-ya...@emcraft.com you wrote: Hello everybody, meanwhile I've fixed one more issue in mpc512x_dma driver. Any comments? Anybody interrested in this driver? Piotr? Still unsure how to deal with bitfield structures in IO space... Regards, Ilya. Signed-off-by: Ilya Yanok ya...@emcraft.com Cc: Piotr Ziecik ko...@semihalf.com Tested-by: Wolfgang Denk w...@denx.de Acked-by: Wolfgang Denk w...@denx.de Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have often regretted my speech, never my silence. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [REPOST][PATCH] mpc8308: fix USB DR controller initialization
Dear Ilya Yanok, In message 1288137756-3389-1-git-send-email-ya...@emcraft.com you wrote: MPC8308 has ULPI pin muxing settings in SICRH register, bits 17-18 which is different from both MPC8313 and MPC8315. Also MPC8308 doesn't have REFSEL, UTMI_PHY_EN and OTG_PORT fields in the USB DR controller CONTROL register. Signed-off-by: Ilya Yanok ya...@emcraft.com Tested-by: Wolfgang Denk w...@denx.de Acked-by: Wolfgang Denk w...@denx.de Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you think the problem is bad now, just wait until we've solved it. Epstein's Law ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PPC4xx: ADMA separating SoC specific functions
of boards. You only replied We select the architecture at build time. without any explanation if there is a pressing technical reason to do it this way, or if this was just a arbitrary decision. The same goes for putting so much source code in a header file - I really see no technical need for this (especially not if you build for a single architecture only). Also I wonder why you still keep so many 440SPe specific code in the common file, even though you just create new 440SPe specific header and source files. Please elucidate. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Unix is simple, but it takes a genius to understand the simplicity. - Dennis Ritchie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mpc512x_dma: add MPC8308 support
Dear Ilya Yanok, In message 1285676696-5358-4-git-send-email-ya...@emcraft.com you wrote: MPC8308 has pretty much the same DMA controller as MPC5121 and this patch adds support for MPC8308 to the mpc512x_dma driver. Signed-off-by: Ilya Yanok ya...@emcraft.com Cc: Piotr Ziecik ko...@semihalf.com --- drivers/dma/Kconfig |2 +- drivers/dma/mpc512x_dma.c | 95 +--- 2 files changed, 72 insertions(+), 25 deletions(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 9520cf0..5c5e95b 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -100,7 +100,7 @@ config FSL_DMA config MPC512X_DMA tristate Freescale MPC512x built-in DMA engine support - depends on PPC_MPC512x + depends on PPC_MPC512x || PPC_MPC831x Is MPC831x correct here? My understanding is that MPC831x processors have yet other DMA cotnrollers, and we're on a MPC8308 here? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A little knowledge is a dangerous thing.- Doug Gwyn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
Dear Tirumala Marri, In message 7707889dee57e97ad50b4ce5c7697...@mail.gmail.com you wrote: +/** + * ppc440spe_can_rxor - check if the operands may be processed with RXOR + */ +static int ppc440spe_can_rxor(struct page **srcs, int src_cnt, size_t len) Again, should this then not be in ppc440spe specific files? It seems the split / generalization is highly incomplete yet. [Marri] Some of the stuff can go into ppc440spe-dma.h. This is just Beginning to add more new DMA engines support. I expect more changes to come in. Why would that go into a header file? This is source code, not header stuff. It should stay in a .c file! [Note that Ilya asked the same question.] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Intel's new motto: United we stand. Divided we fall! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] PPC4xx: Generelizing drivers/dma/ppc4xx/adma.c
Dear tma...@apm.com, In message 1284774145-14543-1-git-send-email-tma...@apm.com you wrote: This patch generalizes the existing drver/dma/ppc4xx/adma.c, so that common code can be shared between different similar DMA engine drivers in other SoCs. ... * This driver supports the asynchrounous DMA copy and RAID engines available - * on the AMCC PPC440SPe Processors. + * on the AMCC PPC4XX Processors. Will this driver ever include any 40x processors? If not, you probably should use 44x instead (here and everywhere in the rest of the code). diff --git a/drivers/dma/ppc4xx/ppc4xx-adma.h b/drivers/dma/ppc4xx/ppc4xx-adma.h new file mode 100644 index 000..7457237 --- /dev/null +++ b/drivers/dma/ppc4xx/ppc4xx-adma.h ... +#include linux/of.h +#include linux/of_platform.h +#include asm/dcr.h +#include asm/dcr-regs.h +#include adma.h +#include ppc440spe-dma.h + +/* Default polynomial (for 440SP is only available) */ +#define PPC4XX_DEFAULT_POLY 0x4d Should this go into ppc440spe-dma.h? +/* The list of channels exported by ppc440spe ADMA */ +struct list_head + ppc4xx_adma_chan_list = LIST_HEAD_INIT(ppc4xx_adma_chan_list); + +/* This flag is set when want to refetch the xor chain in the interrupt + * handler + */ +static u32 do_xor_refetch; + +/* Pointer to DMA0, DMA1 CP/CS FIFO */ +static void *ppc440spe_dma_fifo_buf; Seems this should go into ppc440spe-dma.h? +/* This array is used in data-check operations for storing a pattern */ +static char ppc440spe_qword[16]; + +static atomic_t ppc4xx_adma_err_irq_ref; +static dcr_host_t ppc440spe_mq_dcr_host; +static unsigned int ppc440spe_mq_dcr_len; Ditto? +static unsigned long ppc440spe_rxor_state; + +static struct page *ppc440spe_rxor_srcs[32]; And here again - please check globally! +/** + * ppc440spe_can_rxor - check if the operands may be processed with RXOR + */ +static int ppc440spe_can_rxor(struct page **srcs, int src_cnt, size_t len) Again, should this then not be in ppc440spe specific files? It seems the split / generalization is highly incomplete yet. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What can it profit a man to gain the whole world and to come to his property with a gastric ulcer, a blown prostate, and bifocals? -- John Steinbeck, _Cannery Row_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] PPC4xx: Merge xor.h and dma.h into onefile ppc440spe-dma.h
Dear tma...@apm.com, In message 1284774162-14652-1-git-send-email-tma...@apm.com you wrote: From: Tirumala Marri tma...@apm.com This patch combines drivers/dma/ppc4xx/xor.h and driver/dma/dma/ppc4xx/dma.h into drivers/dma/ppc4xx/ppx440spe-dma.h . Signed-off-by: Tirumala R Marri tma...@apm.com --- drivers/dma/ppc4xx/dma.h | 223 - drivers/dma/ppc4xx/ppc440spe-dma.h | 318 drivers/dma/ppc4xx/xor.h | 110 - 3 files changed, 318 insertions(+), 333 deletions(-) Please use -M with git format-patch so it detects renames (here we should probably see a rename from dma.h into ppc440spe-dma.h [plus some changes]) instead of a remove plus add file. That would make it much easier to review your changes. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It's a small world, but I wouldn't want to paint it. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
Dear Scott Wood, In message 20100909173735.503c4...@schlenkerla.am.freescale.net you wrote: It actually can load an ELF file, but it doesn't currently support passing a device tree to it (only argc/argv text arguments, or some vxworks stuff). I see no problems to extend U-Boot such that we support booting Linux kernel images in form of ELF files. Ideally these should be wrapped into FIT images to allow for easy combination of kernel and FDT into a single file (useful for netboot). I've never understood the reasoning for that uImage wrapper thingy. Definitely causes more problems than it solves in my experience. Wolfgang was just defending it on the U-Boot list the past couple days... seems like the main thing in its favor is the CRC, especially as a final check before reflashing an image. The additional file header serves a number of purposes; even if they seem of little use to a developer they are really helpful in production and maintenance/repair. Assume you were to find out why a system (returned from a customer) does not boot any more. Being able to identify the kernel image in flash, with information about version (name string), image build time and size is really, really helpful then. Of course it's also helpful to be able to check if the image is OK or for example has been (partially) overwritten. The checksum protection is indeed a VERY useful thing. If we hade similar checksum protection on the device tree we would have been able to recognize the memory corruption that triggered this thread MUCH easier. Acutally this is my biggest critique on the FDT blob: that we cannot detect corruptions like this. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is a good thing for an uneducated man to read books of quotations. - Sir Winston Churchill _My Early Life_ ch. 9 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Combining defconfigs for 44x based boards
Dear Tirumala Marri, In message 49073d172310031addb3aa7d08a60...@mail.gmail.com you wrote: I am thinking that we can combine arches, Canyonlands, glacier, redwood and eiger can be combined as ppc46x_defconfig. We already have arch/powerpc/configs/ppc40x_defconfig and arch/powerpc/configs/ppc44x_defconfig in mainline. What's wrong with using these? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de CONSUMER NOTICE: Because of the Uncertainty Principle, It Is Impossible for the Consumer to Find Out at the Same Time Both Precisely Where This Product Is and How Fast It Is Moving. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: drivers/ata/sata_dwc_460ex.c fails to build
Dear Rupjyoti Sarmah, In message 5205dc59ca0e0fd65e50d80eeff60...@mail.gmail.com you wrote: The current mainline 2.6.36-rc3 does not report any error while building the SATA driver. It reports a lot of warnings, though: - git describe v2.6.36-rc3 In file included from drivers/ata/sata_dwc_460ex.c:38: drivers/ata/libata.h:31:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c:44:1: warning: DRV_VERSION redefined drivers/ata/libata.h:32:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_exec_command_by_tag': drivers/ata/sata_dwc_460ex.c:1356: warning: passing argument 1 of 'ata_get_cmd_descript' makes integer from pointer without a cast drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_qc_issue': drivers/ata/sata_dwc_460ex.c:1476: warning: 'err' is used uninitialized in this function drivers/ata/sata_dwc_460ex.c:1465: note: 'err' was declared here drivers/scsi/constants.c: In function 'scsi_print_sense': drivers/scsi/constants.c:1407: warning: zero-length printf format string drivers/scsi/constants.c:1413: warning: zero-length printf format string drivers/scsi/constants.c: In function 'scsi_print_result': drivers/scsi/constants.c:1456: warning: zero-length printf format string drivers/scsi/sd.c: In function 'sd_print_sense_hdr': drivers/scsi/sd.c:2628: warning: zero-length printf format string drivers/scsi/sd.c:2630: warning: zero-length printf format string drivers/scsi/sd.c: In function 'sd_print_result': drivers/scsi/sd.c:2636: warning: zero-length printf format string And the ``'err' is used uninitialized'' warning is indeed a valid one. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What is mind? No matter. What is matter? Never mind. -- Thomas Hewitt Key, 1799-1875 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re:
Dear Rupjyoti, Prodyut, Mark, two weeks ago I wrote: In message 20100818205646.57783157...@gemini.denx.de you wrote: drivers/ata/sata_dwc_460ex.c fails to build in current mainline: ... Do you have any hints how to fix that? Any comments or ideas how to fix this? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Time is an illusion perpetrated by the manufacturers of space. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[no subject]
Dear Rupjyoti, drivers/ata/sata_dwc_460ex.c fails to build in current mainline: ... CC drivers/ata/sata_dwc_460ex.o drivers/ata/sata_dwc_460ex.c:43:1: warning: DRV_NAME redefined In file included from drivers/ata/sata_dwc_460ex.c:38: drivers/ata/libata.h:31:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c:44:1: warning: DRV_VERSION redefined drivers/ata/libata.h:32:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_exec_command_by_tag': drivers/ata/sata_dwc_460ex.c:1356: warning: passing argument 1 of 'ata_get_cmd_descript' makes integer from pointer without a cast drivers/ata/sata_dwc_460ex.c: At top level: drivers/ata/sata_dwc_460ex.c:1592: warning: 'struct of_device' declared inside parameter list drivers/ata/sata_dwc_460ex.c:1592: warning: its scope is only this definition or declaration, which is probably not what you want drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_probe': drivers/ata/sata_dwc_460ex.c:1607: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1614: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1616: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1622: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1628: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1630: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1646: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1650: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1652: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1658: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1660: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1667: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1676: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1678: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1691: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1693: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c: At top level: drivers/ata/sata_dwc_460ex.c:1705: warning: 'struct of_device' declared inside parameter list drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_remove': drivers/ata/sata_dwc_460ex.c:1707: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1720: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c: At top level: drivers/ata/sata_dwc_460ex.c:1736: warning: initialization from incompatible pointer type drivers/ata/sata_dwc_460ex.c:1737: warning: initialization from incompatible pointer type make[2]: *** [drivers/ata/sata_dwc_460ex.o] Error 1 Do you have any hints how to fix that? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Few people do business well who do nothing else. -- Philip Earl of Chesterfield ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx) [REPOST]
Hello Kumar, hello Kim, can you _please_ comment? Thanks. In message 20100729212043.4258c152...@gemini.denx.de I wrote: Dear Kumar Kim, any comments on this issue? Thanks. In message 4c48b384.1020...@emcraft.com Ilya Yanok wrote: Hi Kumar, Kim, Josh, everybody, I hope to disturb you but I haven't got any reply for my first posting... I've found that MSI work correctly with older kernels on my MPC8308RDB board and don't work with newer ones. After bisecting I've found that the source of the problem is commit 3da34aa: commit 3da34aae03d498ee62f75aa7467de93cce3030fd Author: Kumar Gala ga...@kernel.crashing.org Date: Tue May 12 15:51:56 2009 -0500 powerpc/fsl: Support unique MSI addresses per PCIe Root Complex Its feasible based on how the PCI address map is setup that the region of PCI address space used for MSIs differs for each PHB on the same SoC. Instead of assuming that the address mappes to CCSRBAR 1:1 we read PEXCSRBAR (BAR0) for the PHB that the given pci_dev is on. Signed-off-by: Kumar Gala ga...@kernel.crashing.org I can see BAR0 initialization for 85xx/86xx hardware but not for 83xx neigher in the kernel nor in U-Boot (that makes me think that all 83xx can be affected). I'm not actually an PCI expert so I've just tried to write IMMR base address to the BAR0 register from the U-Boot to get the correct address but this doesn't help. Please direct me how to init 83xx PCIE controller to make it compatible with this patch. Kim, I think MPC8315E is affected too, could you please test it? Thanks in advance. Regards, Ilya. Best regards, Wolfgang Denk Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In the beginning, there was nothing, which exploded. - Terry Pratchett, _Lords and Ladies_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx) [REPOST]
Dear Kumar Kim, any comments on this issue? Thanks. In message 4c48b384.1020...@emcraft.com Ilya Yanok wrote: Hi Kumar, Kim, Josh, everybody, I hope to disturb you but I haven't got any reply for my first posting... I've found that MSI work correctly with older kernels on my MPC8308RDB board and don't work with newer ones. After bisecting I've found that the source of the problem is commit 3da34aa: commit 3da34aae03d498ee62f75aa7467de93cce3030fd Author: Kumar Gala ga...@kernel.crashing.org Date: Tue May 12 15:51:56 2009 -0500 powerpc/fsl: Support unique MSI addresses per PCIe Root Complex Its feasible based on how the PCI address map is setup that the region of PCI address space used for MSIs differs for each PHB on the same SoC. Instead of assuming that the address mappes to CCSRBAR 1:1 we read PEXCSRBAR (BAR0) for the PHB that the given pci_dev is on. Signed-off-by: Kumar Gala ga...@kernel.crashing.org I can see BAR0 initialization for 85xx/86xx hardware but not for 83xx neigher in the kernel nor in U-Boot (that makes me think that all 83xx can be affected). I'm not actually an PCI expert so I've just tried to write IMMR base address to the BAR0 register from the U-Boot to get the correct address but this doesn't help. Please direct me how to init 83xx PCIE controller to make it compatible with this patch. Kim, I think MPC8315E is affected too, could you please test it? Thanks in advance. Regards, Ilya. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A good aphorism is too hard for the tooth of time, and is not worn away by all the centuries, although it serves as food for every epoch. - Friedrich Wilhelm Nietzsche _Miscellaneous Maxims and Opinions_ no. 168 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/2] Adding DTS for the STx GP3-SSA MPC8555 board
Dear Bradley Hughes, In message aanlktimmb_pshxaidvbffdbcqhrly13qiz9g2ez1v...@mail.gmail.com you wrote: This version uses fsl,mpc8555... instead of fsl,85... notation. Such comments should go below the --- line. There is also an 8541 version of this board so DTS for this board is specific to the 8555 processor. Another patch is coming to fix-up other DTS that use old notation. Ditto. Signed-off-by: Bradley Hughes bhug...@silicontkx.com --- ^^^ Insert comments after this line. Hm... have you verified that PCI is working? I tried enabling drivers for the ITE8211 PATA controller, but it doesn't seem to work for me (and yes, I did add the required pata_it821x.noraid=1 to the bootargs). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To be a winner, all you need to give is all you have. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1]460EX on-chip SATA driverresubmisison
'sata_dwc_probe': drivers/ata/sata_dwc_460ex.c:1638: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c:1639: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c:1641: error: 'struct ata_port' has no member named 'ioaddr' make[2]: *** [drivers/ata/sata_dwc_460ex.o] Error 1 make[1]: *** [drivers/ata] Error 2 make: *** [drivers] Error 2 Does this require any specific kernel version? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A direct quote from the Boss: We passed over a lot of good people to get the ones we hired. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1]460EX on-chip SATA driverresubmisison
Dear Rupjyoti Sarmah, In message 3b928476b2fffdcf0694e5436e8a4...@mail.gmail.com you wrote: I took the mainline kernel v2.6.35-rc3 and downloaded using the git download link. I created the patch on 6/24/2010 after doing a git pull. With the kernel tree on 6/24/2010 the driver compiled. I also tested the functionality on the SATA drive it worked. v2.6.35-rc3 was released on June 11, 13 days before 6/24/2010. Can you please give the exact git commit ID so I can try reproducing this? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There comes to all races an ultimate crisis which you have yet to face One day our minds became so powerful we dared think of ourselves as gods. -- Sargon, Return to Tomorrow, stardate 4768.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1]460EX on-chip SATA driverresubmisison
: *** [drivers] Error 2 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Often it is fatal to live too long. - Racine ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1]460EX on-chip SATA driverresubmisison
Dear Josh Boyer, In message 20100630200325.gd7...@zod.rchland.ibm.com you wrote: The driver doesn't depend on CONFIG_ATA_SFF in it's Kconfig file, but seems to require it at build time. Isn't that something that needs fixing in the driver? Right. Next question is if this is really needed for this driver. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Copy from one, it's plagiarism; copy from two, it's research. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ftp login problem using wu-ftpd
Dear Stevan Ignjatovic, In message 1277820991.4257.18.ca...@stevan you wrote: I ported Linux-2.6.30-rc8 on my custom mpc885 board. The filesystem I am using is jffs2 which I created from eldk-4.2/ppc_8xx/images/ramdisk_image.gz. Linux boots fine and I can telnet to the board but I cannot ftp: ... Here ftp connection hangs. Do I have to create another user (beside root) in order to make ftp connection? Earlier, when I was using 2.4 linux I didn't have problems with ftp connection as root. check your kernel configuration. You might be missing options like CONFIG_UNIX98_PTYS or CONFIG_LEGACY_PTYS or similar. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Every program has at least one bug and can be shortened by at least one instruction - from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/9] Add Synopsys DesignWare HS USB OTG Controller driver.
Dear Fushen Chen,
In message 1277846824673-git-send-email-fc...@apm.com you wrote:
Implements DWC OTG USB Host Controller Driver (HCD) and interface to
USB Host controller Driver framework.
Signed-off-by: Fushen Chen fc...@apm.com
Signed-off-by: Mark Miesfeld mmiesf...@apm.com
---
drivers/usb/otg/dwc_otg_hcd.c | 2397
+
drivers/usb/otg/dwc_otg_hcd.h | 421
2 files changed, 2818 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/otg/dwc_otg_hcd.c
create mode 100644 drivers/usb/otg/dwc_otg_hcd.h
Why are you posting this old driver version without trying to sync
against our tree which includes a number of fixes - you should know
about these.
...
+ do {
+ hcchar.d32 = dwc_read_reg32(hc_regs-hcchar);
+ if (++count 1) {
+ printk(KERN_ERR %s: Unable to clear halt on
+ channel %d\n, __func__, i);
+ break;
+ }
+ } while (hcchar.b.chen);
+ }
For example, here you are missing
commit 018b43db153da063182c87be2eaad037cba2d879
Author: Stefan Roese s...@denx.de
Date: Thu Sep 24 17:15:06 2009 +0200
USB: Fix timeout problem with polling loops in DWC USB-OTG driver
In [PATCH 6/9] Add Synopsys DesignWare HS USB OTG Controller driver
you are missing
commit 538fe70d696bc5e694ab08e9627a99a0b11358ec
Author: Stefan Roese s...@denx.de
Date: Wed Sep 23 08:50:29 2009 +0200
USB: Fix problem with reconnection in DWC USB-OTG driver
etc.
Please update your code and resubmit.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The biggest difference between time and space is that you can't reuse
time. - Merrick Furst
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/9] Add Synopsys DesignWare HS USB OTG Controller driver.
Dear David Daney, In message 4c2a8038.50...@caviumnetworks.com you wrote: Why are you posting this old driver version without trying to sync against our tree which includes a number of fixes - you should know about these. This could be a question with an obvious answer, but which tree are you referring to when you say 'our tree'? git://git.denx.de/linux-2.6-denx.git Fushen Chen should know this, as the fixes I've mentioned were part of contract/support work for Applied Micro. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The Wright Bothers weren't the first to fly. They were just the first not to crash. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: JFFS2 corruption when mounting filesystem with filenamesoflength 7
Dear Steve Deiters,
In message 181804936abc2349be503168465576460f20d...@exchserver.basler.com you
wrote:
I think there may be something weird going on with the memcpy
in my build. If I use the following patch I no longer get
errors when I mount the filesystem. All I did was replace
the memcpy with a loop.
I'm not sure what's special about this particular use of
memcpy. I can't believe that things would be working as well
as they do if memcpy was broken in general.
This is on a PowerPC 32 bit build for a MPC5121. I am using
a GCC 4.1.2 to compile. Is anyone aware of any issues with
memcpy in this configuration?
Thanks.
It seems this processor is mangling the data when it access unaligned
addresses into Flash with a lwz instruction. The memcpy implementation
in copy_32.S aligns the destination, leaving the source possibly
unaligned. In this particular instance the source is an address into my
Flash address space which is causing the problem. When the filenames
were 8 it always does a bytewise copy which is why I wasn't having
problems with those.
It seems this only occurs when I have the translation enabled. If I
clear the DR bit in the MSR and then repeat the instruction with the
corresponding physical address it will read correctly.
I'm not sure if this is expected behavior with this core. I can fix at
least this one problem by using memcpy_fromio since it does alignment
checks for the source and destination.
Both the MPC52xx and MPC512x have know problems (silent data
corruption) with unaligned accesses on the local bus.
This can be trivially demonstrated in U-Boot by reading the flash
memory with 32 bit accesses; for example like this:
= md FC0C 20
fc0c: 7012ab65 01616464 636f6e73 3d736574p..e.addcons=set
fc0c0010: 656e7620 626f6f74 61726773 20247b62env bootargs ${b
fc0c0020: 6f6f7461 7267737d 20636f6e 736f6c65ootargs} console
fc0c0030: 3d247b63 6f6e736f 6c657d2c 247b6261=${console},${ba
fc0c0040: 75647261 74657d00 61646469 703d7365udrate}.addip=se
fc0c0050: 74656e76 20626f6f 74617267 7320247btenv bootargs ${
fc0c0060: 626f6f74 61726773 7d206970 3d247b69bootargs} ip=${i
fc0c0070: 70616464 727d3a24 7b736572 76657269paddr}:${serveri
= md FC0C0001 20
fc0c0001: 65726901 0063 003d 0065eric...=...e
fc0c0011: 0062 0061 0020 006f...b...a... ...o
fc0c0021: 0072 0020 0073 003d...r... ...s...=
fc0c0031: 006f 006c 0024 0075...o...l...$...u
fc0c0041: 0074 0061 0070 0074...t...a...p...t
fc0c0051: 0020 0074 0073 0062... ...t...s...b
fc0c0061: 0061 007d 003d 0070...a...}...=...p
fc0c0071: 0072 007b 0076 0070...r...{...v...p
I'm not sure what the proper fix is for this. If I use memcpy_fromio I
think I'll just run into problems somewhere else. Any other
suggestions?
See http://article.gmane.org/gmane.comp.boot-loaders.u-boot/80278 for
how we fix this in U-Boot.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
On two occasions I have been asked [by members of Parliament!],
'Pray, Mr. Babbage, if you put into the machine wrong figures, will
the right answers come out?' I am not able rightly to apprehend the
kind of confusion of ideas that could provoke such a question.
- Charles Babbage
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] mpc5200 ac97 gpio reset
Dear Jon Smirl, In message aanlktimis90kr5uqhdbq02osd94dn08soitm51ylr...@mail.gmail.com you wrote: Would making a change in uboot be a better solution? Eric, can you verify if changing uboot also fixes the problem? To me it seems better if the driver itself does what needs to be done instead of relying on specific settings that may or may not be done in U-Boot. Keep in mind that drivers may be loaded as modules, and that we even see cases where the same port serves multiple purposes by loading different driver modules (yes, this is not exactly a clever idea, but hardware designers come up with such solutions). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The typical page layout program is nothing more than an electronic light table for cutting and pasting documents. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH]460EX on-chip SATA driverkernel 2.6.33resubmission
Dear Rupjyoti Sarmah, In message 201006041226.o54cqh2v017...@amcc.com you wrote: This patch enables the on-chip DWC SATA controller of the AppliedMicro processor 460EX. Signed-off-by: Rupjyoti Sarmah rsar...@appliedmicro.com Signed-off-by: Mark Miesfeld mmiesf...@appliedmicro.com Signed-off-by: Prodyut Hazarika phazar...@appliedmicro.com --- drivers/ata/Kconfig |9 + drivers/ata/Makefile |1 + drivers/ata/sata_dwc_460ex.c | 1808 ++ 3 files changed, 1818 insertions(+), 0 deletions(-) create mode 100644 drivers/ata/sata_dwc_460ex.c This driver needs fixing. It will not compile against recent kernel versions. ... diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c new file mode 100644 index 000..e6e2896 --- /dev/null +++ b/drivers/ata/sata_dwc_460ex.c @@ -0,0 +1,1808 @@ ... +#include linux/kernel.h +#include linux/module.h +#include linux/init.h +#include linux/device.h +#include linux/of_platform.h +#include linux/libata.h +#include libata.h + +#include scsi/scsi_host.h +#include scsi/scsi_cmnd.h You miss a #include linux/slab.h here. ... + for (i = 0; i SATA_DWC_QCMD_MAX; i++) + hsdevp-cmd_issued[i] = SATA_DWC_CMD_ISSUED_NOT; + + ap-prd = 0;/* set these so libata doesn't use them */ + ap-prd_dma = 0; s/prd/bmdma_prd/ in these two lines (cf. commit f60d7011). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de He had quite a powerful intellect, but it was as powerful like a locomotive, and ran on rails and was therefore almost impossible to steer. - Terry Pratchett, _Lords and Ladies_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc5121e-Real Time Clock
Dear =?iso-8859-1?Q?CTAG_/_Mois=E9s_Dom=EDnguez?=, In message e70643a89af74de1bca25c3c4ae2c...@ctag you wrote: Looking in rtc-mpc5121.c code I didn't find anything related to Keep Alive Register (where TAMP bit is) so I would like to know where this issue is taking into account or if it is really being taking into account in the driver. It is not. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To the systems programmer, users and applications serve only to provide a test load. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash
Dear Josh Triplett, In message 20100326225916.ga5...@feather you wrote: However, according to one of our hardware hackers, Andrew Greenberg (CCed), the STK5200 development breakout board for the TQM5200 *does* have the DMA pins wired up correctly, at least according to its schematic. That doesn't guarantee that the board matches the schematic, of course. We tested CF cards for DMA support some time ago, and IIRC this included the STK5200. Situation was that only very few CF cards actually support DMA (even if they advertise it on the label). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I wish Captain Vimes were here. He wouldn't have known what to do either, but he's got a much better vocabulary to be baffled in. - Terry Pratchett, _Guards! Guards!_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc512x uart: testers wanted
Dear Albrecht =?iso-8859-1?b?RHJl3w==?=, In message 1269696561.224...@antares you wrote: Thanks for the reminder - I sent Anatolij the rebased patch off-list (as I didn't want to clutter the list again with the same patch) 2½ weeks ago, but didn't get any testing results from him yet. If you want to see the patch in the list, too, please just drop me a note. Anatolij is on vacation until mid April. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If that makes any sense to you, you have a big problem. -- C. Durance, Computer Science 234 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux patches for XIP on MPC8xx?
Dear Márton Németh, in message 4ba865d4.1090...@freemail.hu you wrote: I found your homepage at http://www.denx.de/wiki/bin/view/DULG/ConfigureLinuxForXIP back from 2003. Was there any follow up of your patch for kernel 2.4.4? There were very few tests done with later kernel versions, and in all practical system configurations we tested we found that XIP did not give real benefits. Usually execution from flash was slower than when running from RAM, and even booting a (inevitably uncompressed) kernel from flash is typically slower than loading a compressed image to RUM and booting from there. So except for some highly specialized applications (you may also call these exotic configurations) XIP for the Linux kernel does not make much sense to me. I am aware that there are reports which come to completely different conclusions - see for example http://www.elinux.org/Kernel_XIP ; but then look carefully - the examples come from hardware with really slow processors, which are probably not typical any more. Actually this is the first thing you should check: the ratio of processor speed versus flash memory bandwidth versus RAM bandwidth. Today you can usually expect CPU clocks way over 400 MHz, and many systems use DDR, while NOR flash speed has noch changed much. Also check if it is possible to map the flash memory cached for your system (which you definitly want when using XIP from flash); this may prevent some flash access methods from working. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Doubt isn't the opposite of faith; it is an element of faith. - Paul Tillich, German theologian and historian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/4] 8xx: Optimize TLB Miss code.
Dear Joakim Tjernlund, In message of1413a940.58e7b20e-onc12576e0.003a9000-c12576e0.003ac...@transmode.se you wrote: I use NFS. Then I think it is possible NFS gets in the way for stable measurements. Anyone have experience with running lmbench on NFS? NFS may have some influence here, but I doubt it is the primary cause for these variations. The network where Heiko is running these tests is mostly idle, so it should provide fairly constant conditions. Of coursem the use of the network on the MPC8xx itself will add to the variation, but again I would not expect so big differences. Heiko - there is a 10 GB disk attached to the tqm8xx system; I think there should be a usable root file system on it, but I cannot remember the actual state. Maybe we can use that. Please contact me on jabber this afternoon! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Living on Earth may be expensive, but it includes an annual free trip around the Sun. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/4] 8xx: Optimize TLB Miss code.
Dear Heiko, thanks for running the tests. In message 4b8f8bb4.6070...@denx.de you wrote: here the results: run version 1-4 2.6.33-rc6 without your patches 5-8 2.6.33-rc6 with all your patches 9-12 2.6.33-rc6 with patches 1,2 and 4 (without 8xx: Don't touch ACCESSED when no SWAP) 13-16 2.6.33-rc6 with all your patches and CONFIG_PIN_TLB=y So CONFIG_PIN_TLB imroves the performance as expected, while the other patches don;t show any measurable improvememt - or am I reading the results incorrectly? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de And now remains That we find out the cause of this effect, Or rather say, the cause of this defect... -- Hamlet, Act II, Scene 2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Endian/__BYTE_ORDER question
Dear Joakim Tjernlund, In message of918aa866.3ed427eb-onc12576c7.005cbee4-c12576c7.005cf...@transmode.se you wrote: I have no idea how it is actually done in the kernel code... but gcc defines it: gcc -dM -E -x c - '' | grep ENDIAN #define __BIG_ENDIAN__ 1 #define _BIG_ENDIAN 1 That doesn't define __BYTE_ORDER. Try the same gcc command on a file that #includes stdlib.h and you will get both __BIG_ENDIAN and __LITTLE_ENDIAN For me this appears to work: On x86: $ echo '#include stdlib.h' | gcc -dM -E -x c - | grep ENDIAN #define _ENDIAN_H 1 #define PDP_ENDIAN __PDP_ENDIAN #define __PDP_ENDIAN 3412 #define BIG_ENDIAN __BIG_ENDIAN #define __BYTE_ORDER __LITTLE_ENDIAN #define __LITTLE_ENDIAN 1234 #define __BIG_ENDIAN 4321 #define LITTLE_ENDIAN __LITTLE_ENDIAN On PowerPC: $ echo '#include stdlib.h' | gcc -dM -E -x c - | grep ENDIAN #define __BIG_ENDIAN__ 1 #define __PDP_ENDIAN 3412 #define __LITTLE_ENDIAN 1234 #define BIG_ENDIAN __BIG_ENDIAN #define _BIG_ENDIAN 1 #define __BYTE_ORDER __BIG_ENDIAN #define _ENDIAN_H 1 #define __BIG_ENDIAN 4321 #define PDP_ENDIAN __PDP_ENDIAN #define LITTLE_ENDIAN __LITTLE_ENDIAN In both cases __BYTE_ORDER is set to a sane value. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Copy from one, it's plagiarism; copy from two, it's research. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: simpleImage.XX and large kernels
Dear John Williams, In message 1d3f23371002080247j17138famcf4e4aebc1ae0...@mail.gmail.com you wrote: I'm looking at the simpleImage.XXX make target (PPC 405/440), and it seems that by default the arch/powerpc/boot/wrapper script places the bootwrapper at 0x40, effectively setting a limit on the maximum bootable kernel size. For various reasons we'd like to be able to put a fairly complete rootfs as an initramfs, which obviously blows past a 4Mbyte limit very quickly. Short of adding a new 'platform' option and associated hackery through the powerpc/boot Makefiles and wrapper, is there a quick and clean way I can tell the boot wrapper to link at a higher address? Is there any specific reason why you want to use simpleImage, instead of using a normal uImage either bundled with your ramdisk image as a classic multifile image, or (recommended) as a FIT image? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It's all Klatchian to me. - Terry Pratchett Stephen Briggs, _The Discworld Companion_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [net-next-2.6 PATCH 2/3] fs_enet: Add support for MPC512x to fs_enet driver
Dear Wolfgang Arnd, In message 4b5c5bdf.6020...@grandegger.com you wrote: Arnd Bergmann wrote: ... Is there any chance of building a kernel that runs on both mpc8xx and mpc5121? AFAIK, the 5121 is built on a 6xx core which is fundamentally incompatible with 8xx due to different memory management etc. It is my understanding as well that you cannot have a single image that boots both on 8xx and on 6xx cores. The focus was more on things like supporting MPC5200 and MPC512x with the same image. Since this makes it all a compile-time decision, it should be solvable with a very small number of carefully placed #ifdef in the header files an no runtime detection at all. Obviously this approach would not work for drivers that want to be portable across different register layouts on otherwise compatible platforms. You are probably right and your proposal would likely result in more transparent (less ugly) code. There has been some discussion about unifying FEC drivers when the patches (with the same subject) have been submitted for the first time in May last year, but it was not about 512x and 8xx, IIRC. You can re-read this discussion here: http://patchwork.ozlabs.org/patch/26927/ ee especiall Grant's note of 2009-05-21 15:36:11: If it looks too ugly, then just fork the driver. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Immortality consists largely of boredom. -- Zefrem Cochrane, Metamorphosis, stardate 3219.8 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 02/13] powerpc/5200: LocalPlus driver: use SCLPC register structure
Dear Grant, In message fa686aa4100115g3451c9b9h4d6c551afd569...@mail.gmail.com you wrote: Please don't. I know that a lot of other 5200 code uses register map structures in this way, but I consider it bad practice. I coded this May I ask _why_ you consider this bad practice? Is a structure not the most natural way to encode the specifics of a hardware interface (address offet, bus width, etc.) in C? What do you recommend instead? Using lists of register offsets (without any type information) as for example ARM is doing? driver without a structure for a reason. The reason I haven't removed Could you please explain this reason? I'm trying to understand if this is a MPC52xx specific reasoning, or if you apply this to all of PowerPC, or generally to all kernel code? And: is this just your personal preferences, or generally agreed on? Thanks in advance, and sorry for asking stupid questions, but your reply surprised me... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Gods don't like people not doing much work. People who aren't busy all the time might start to _think_. - Terry Pratchett, _Small Gods_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 03/13] mpc52xx: add SCLPC register bit definitions
Dear Grant Likely, In message fa686aa4100121u5c943fc7p789c0ec0b41af...@mail.gmail.com you wrote: /* mpc52xx_lpbfifo.c */ #define MPC52XX_LPBFIFO_FLAG_READ (0) -#define MPC52XX_LPBFIFO_FLAG_WRITE (10) -#define MPC52XX_LPBFIFO_FLAG_NO_INCREMENT (11) -#define MPC52XX_LPBFIFO_FLAG_NO_DMA(12) -#define MPC52XX_LPBFIFO_FLAG_POLL_DMA (13) +#define MPC52XX_LPBFIFO_FLAG_WRITE BIT(0) +#define MPC52XX_LPBFIFO_FLAG_NO_INCREMENT BIT(1) +#define MPC52XX_LPBFIFO_FLAG_NO_DMABIT(2) +#define MPC52XX_LPBFIFO_FLAG_POLL_DMA BIT(3) I prefer the (1n) style myself. Indeed, especially as one can argue that (10) should be BIT(31) on Power Architecture systems, where bit 0 is the MSB by definition. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Do not simplify the design of a program if a way can be found to make it complex and wonderful. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next 2/3] can: mscan-mpc5xxx: add support for the MPC521x processor
Dear Wolfram, in message 20100104162441.ga4...@pengutronix.de you wrote: One further note: I couldn't spot any code handling Rev1 of the MPC5121? Do you plan to add such code? If not, we should at least put a comment that it is missing. The binding documentation should be updated as well, as you can't use all options on such revisions. We only support MPC512x Rev. 2 (and later). This is also true for other parts of the mainline kernel code - see for example trhe NAND driver. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Include the success of others in your dreams for your own success. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Dear Peter, In message 87wrzzpq8c@macbook.be.48ers.dk you wrote: Wolfgang Let's make this uImage.old (or uImage.legacy similar) and Wolfgang uImage, then. No, that would break stuff for the existing users. The existing format make/file names shouldn't change. Well, with this argument you can block all progress and freeze all development to some ancient state. When the arch/ppc = arch/powerpc conversionm was done, we had similar issues: the new powerpc uImages would not work as the old ppc uImages dis, because you also needed the device tree blob, or you had to use the cuImage files. Note that then the decision was made to support the _new_ version as the default, using the default name, which is IMO the Right Thing to do. The FIT images could be called fitimage or uImage.new or something. I disagree. We want to make this the new default, so let's use the default name for this, and continue to support he legacy image format using another name. Also, your approach does not scale. Assume we come up with an even more advanced image format in the future - how should we name it then? uImage.newer ? uImage.verynew ? uImage.new2 ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The world is coming to an end -- save your buffers! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Dear Grant Likely, In message fa686aa41001022108i92596d6qdf2da0e24c347...@mail.gmail.com you wrote: Currently they have to make a legacy uImage, manually run the device tree compiler with the proper flags to generate a board-specific .dtb file, ... or put the .dts files into arch/powerpc/boot/dts and use 'make board.= dtb' multiple board.dtb targets can also be added to CONFIG_EXTRA_TARGETS so that a plain 'make' will build all needed files. Note that the FIT image can also be made to contain a number of DT blobs, and selection of a board profile then can be used to boot the very sane FIT image file on any of the supported boards - so FIT images inherently support multibooting. I see your point. The main goal of the patch was to introduce FIT image support as its the new, more flexible, better, standard image format for U-Boot going forward. Also, lots people aren't aware of FIT images and the cool stuff they can do with them, so what better way to get the word out than getting support for FIT images included in the kernel proper:) Define 'better'. :-) FIT images are better than the old uImage format because they: - allow for strong checksum algorithms like MD5, SHA1, ... (the plain CRC32 method is not good enough if you for example want to run software in a slot machine in Las Vegas). - can combine multiple kernel images, device tree blobs and root file system images in arbitrary combinations; this allows for example for multibooting the same image on different boards by selecting the right DTB, for software updates with automatic fall-back, etc. - can be extended to add new features, images types or whatever in a standard way, using a standard technology (device tree support) which is already present anyway, i. e. without additional code overhead. I do understand your use-case and what problem fit images solve for you. However, from a long term strategy point of view it is a use case that I'm not interested in actively supporting for two reasons. The first is that I think it is in our best interest to encourage the mind set that the hardware description is separate from the operating system image, and so they should be stored and updated separately. I How do you boot systems over network, then? Normally you always download only a single image file. How do you explain this to system vendors? They have a very reasonable request to offer only one image file to their customers. look at the unexpected ecosystem of distributions that has sprung up around wireless routers (ie OpenWRT and the like) and Linux cell phones (ie. Cyanogen Mod) where there is a huge range of hardware. The userspace can pretty much run on any of them excepting minor configuration changes. The embedded space is becoming more PCs in Right. So let's be able to provide kernel images that fit intot he same pattern - that can be used on a range of platforms, for example by embedding multiple DTBs. Requesting that we manage a kernel mage plus a collection of DTBs and that eveybody has to install the only working correctly combination seems to be a bad idea to me. this regard, and I know that multiplatform is a big deal for some of the users. I'm not interested in encouraging any behaviour that will scuttle deployment of multiplatform kernels. (That being said, I'm You misunderstand. FIT images do not scuttle multiplatform kernels. Instead they support this much better, as they allow to bundle the repsective DTBs into one image file. not going to actively sabotage people who want to put dtb sections into the kernel images either. I understand that at times it is necessary, and there are numerous examples of this already in the kernel tree; specifically to support firmware that doesn't implement arch/powerpc's boot interface) Even if the boot loader supports it, it is usually pretty benefical (especially during development) if you can do this. I'd be okay (perhaps not happy, but okay) with merging fitImage and fitImage.initrd targets (no dtb). I will resist merging fitImage.% and fitImage.initrd.% targets because I see that very much as a project specific deployment target and I'm not convinced yet that it the pattern is right or that it is even needed in the kernel at all. Is this just your personal opinion, or do you think that this is really what a majority of kernel developers and users are wanting? Speaking for myself, I have to admit that I don't understand and don't share this attitude. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The optimum committee has no members. - Norman Augustine ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org
Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Dear Grant Likely, In message fa686aa41001022113o46bad9d2xf6c026f5fa3e8...@mail.gmail.com you wrote: Let's make this uImage.old (or uImage.legacy similar) and uImage, then. I'm not interested in renaming the target name for the current uImage format. I think it will cause too much breakage and pain to do so. We did this before, and the argument then was progress. Keep in mind that the old arch/ppc uImage file is much more compatible to the current arch/powerpc cuImage target than to the current uImage. I think the same should be done here. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any sufficiently advanced bug is indistinguishable from a feature. - Rich Kulawiec ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Dear Grant Likely, In message fa686aa41001022118w6b41765ld145c646bfca9...@mail.gmail.com you wrote: As I said in a previous email; I understand the need for certain scenarios, but in the general case it is not the mode that I think should be encouraged. I don't want to merge additional targets for .dtb embedded in the kernel image unless absolutely necessary, and I want developers to have the mindset that .dtbs should be separate from the kernel; and should be quasi-stable (or at least more stable than the kernel itself) because I think that multiplatform is important, and is going to become more important in the future. So I don't want to support it by default; but OTOH, I'm not going to actively prevent embedded .dtb blobs either. But by blocking the addition of such a make target you do actively prevent this, don;t you? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The years of peak mental activity are undoubtedly between the ages of four and eighteen. At four we know all the questions, at eighteen all the answers. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Dear Peter, In message 1262301038.29396.137.ca...@localhost.localdomain you wrote: Why chose a different name at all? We could still call it uImage, meaning U-Boot image - U-Boot is clever enought o detect automatically if we pass it an old style or a fit image. I agree with your point to an extent, but having 2 types of uImages is somewhat confusing to a user, even if U-Boot can differentiate between them. And if the legacy image and FIT image had the same Make target, how does a user specify which type they want to build? The fact that both legacy and FIT images would reside at arch/powerpc/boot/uImage doesn't make things any less confusing to Joe User. Agreed. Currently U-Boot supports booting: 1 legacy uImages 2 new Flattened Image Tree (FIT) uImages The legacy uImage format has a number of restrictions not unsimilar to the restrictions we had in the bootloader / kernel interface when using the old binary bd_info data structur. For the kernel interface this has been replaced by using the device tree, and I would like to see the same happen in U-Boot. The new FIT image type should become the default, and old legacy images should only be generated upon special request (i. e. if some- one needs these for compatibility with an old, not yet FIT-aware version of the boot loader). What do you think about changing the U-Boot documentation to rename those 2 image types to: 1 uImages 2 FIT Images Let's make this uImage.old (or uImage.legacy similar) and uImage, then. The FIT image is a relatively generic image type - its just a blob that dtc created from a device tree and some input binaries. In my mind its not intimately tied to U-Boot, at least not conceptually. The legacy Correct. The intention was to provide an open and somewhat standardized format that can be easily extended for new requirements, whatever these may be. uImages have to agree with U-Boot's header format defined in the U-Boot source code, so the uImage name does make sense with respect to the legacy uImages. Well, you can read uImage as universal Image, which kind of fits the FIT approach :-) My vote would be to make the Linux FIT target rule fitImage and then update the U-Boot documentation to make obvious the differences between uImages and FIT images. I think we should not try to support both legacy and FIT images on the same level - the idea is clearly that legacy images is the old, to be replaced format, while FIT images is the new, to be used as standard format. In this sense I vote for using plain and simple uImage for the (new) standard format, and marking the old format by some .old or .legacy suffix. BTW: note that (IIRC) we don't even have a formal definition of the FIT abbreviation yet ;-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The more data I punch in this card, the lighter it becomes, and the lower the mailing cost. - Stan Kelly-Bootle, The Devil's DP Dictionary ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Dear Grant, In message fa686aa40912301601s6cd0ec4y85b88976159a3...@mail.gmail.com you wrote: Thinking further, I do actually have another concern, at least with regard to the way the current patch set implements things. Is it expected or even recommended that fit images will *always* contain a .dtb image? The current patch only handles the case of a .dtb embedded inside the fit image. I think this can be expected. Historically, the need to pass the dtb image to the Linux kernel, too, was what actually triggered the development of the FIT image format, as it turned out that the old image format with it's fixed binary header was too inflexible. So bundling the kernel image and the device tree blob into one image file is the specific use case this image format was created for (which does not mean that other usage would be impossible). Personally, I don't get any benefit out of the new image format, so I haven't spent any time looking at it. However, I'm concerned about Assume you want to boot over DHCP or similar, where you can provide just a single image file for download. Here it is definitely nice if you can bundle the kernel image and the DTB into one image file. We were able to extend the old so-called multi-file uImage format to handle this situation, too, but it was clear that further extensions were not really possible. We consider the old legace uImage format as something we want to move away from, and the new FIT image format shall be the new default. the drift back towards a different image per target when the move over the last 4 years has been towards multiplatform kernel images. I certainly don't want to encourage embedding the device tree blob into the kernel image, and I'm not very interested in merging code to do that into the kernel tree. If someone really needs to do that for their particular target, it is certainly easy enough for them to weld in the .dtb after the fact before transferring the image to the target, but I want that mode to be the exception, not the rule. This is specific for particular targets, but for specific modes of operation, like booting over the network or other szenarios where transferring a single image file is essential - another example where we often see this request is upgrade procedures for devics, where the vendor wants to be able to distribute a single file for his target systems to avoid customers bricking their devices by chosing incompatible combinations. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/3] powerpc: Add support for creating FIT uImages
Dear Grant, In message fa686aa40912301457l704c324bk511a207d07218...@mail.gmail.com you wrote: Unfortunately, the wrapper script is also being used to do things that are completely unrelated to creating wrapper binaries. FIT images (and uImages) don't use any of the wrapper bits at all. In fact, as seen in this patch, generating them involves bailing out of the wrapper script early to avoid linking the wrapper bits. I think for all types of uImages, the wrapper script is being misused and I don't like the extra complexity that it adds. Agreed. Rather than adding new paths to arch/powerpc/boot/wrapper, I would rather see a new script used for generating FIT image that isn't complicated by all the current wrapper cruft. Also, the Makefile rule doesn't need to depend on $(wrapperbits) which means faster build times when only building uImages. Bonus points if you also convert the uImage target to use the new script; but I'm not demanding that you do that yet. I think if this is handles in a separate script, the legacy uImage support must be handled in this new script, too. Otherwise it would be too difficult to understanmd the relation of the two image formats. Finally, you need to add documentation about the new target to Documentation/powerpc/bootwrapper.txt. Let's keep in mind that the uImage formats (both the old legacy and the new FIT format) are inherently architecture independent. We want to use this same mechanism for example on ARM, and on other architectures as well. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de How many Unix hacks does it take to change a light bulb? Let's see, can you use a shell script for that or does it need a C program? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Dear Grant Likely, In message fa686aa40912301502x48785614ya4dd5c71815a7...@mail.gmail.com you wrote: IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the Makefile so that make behaves more consistently. Speaking of which, the number of '.' in the name is getting rather large. Would you consider using 'fitImage' instead of 'uImage.fit'? Why chose a different name at all? We could still call it uImage, meaning U-Boot image - U-Boot is clever enought o detect automatically if we pass it an old style or a fit image. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If the odds are a million to one against something occuring, chances are 50-50 it will. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: DWC_OTG Issues
Dear Hunter Cobbs, In message 1261340025.3473.15.ca...@mobilinux you wrote: We're using Linux 2.6.30(.3)-denx. We've worked on this issue a bit before, although at the time you were doing some work for AMCC on just accessing devices across a hub in general. We've been using the driver for a few months now and it is very stable on first-use of the driver, but once we close a full-speed port and try to reopen, that's when we get error concerning not being able to allocate resources and getting -28 errors. I don't have anything precise in front of me at the moment, my test equipment is at the office. But this seems to be the issues that lead to the Enhanced Transaction Translation Scheduling changes in the main-line kernel. If you have a detailed bug report, ideally including an easy to reproduce test case to trigger the problem then please feel free to send it to our support address. I'm mainly being, I believe, overly cautious about not including GPL code in the Synopsis driver simply because I'd rather be overly careful than be exposed to some liability later down the road if Synopsis decides they want to make their driver completely proprietary. While the code is available, I'm not sure if we can include code from GPL sources in the Synopsis drivers without requiring the Synopsis driver to become completely GPL. I am also not a lawyer, but I'd rather be cautious. Well, their license is relatively simple: the driver is unsupported, it IS NOT an item of Licensed Software or Licensed Product under any End User Software License Agreement or Agreement for Licensed Product, and you are permitted to use andredistribute this Software in source and binary forms, with or without modification, provided that redistributions of source code must retain this notice. And there is no warranty, of course. IANAL, but I see no risks here. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If I ever needed a brain transplant, I'd choose a teenager's because I'd want a brain that had never been used. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: DWC_OTG Issues
Dear Hunter Cobbs, In message 1261190115.14590.5.ca...@mobilinux you wrote: Hello list. I've run into a rather odd problem. I seem to have a problem with full-speed isochronous transfers across a USB2.0 Hub. I believe this was observed before with the general EHCI drivers in Linux. Which exazct kernel / driver cversions are you talking about? In the latest branch of the kernel, the EHCI driver has some Enhanced Transaction Translation scheduling. This would be great for me to use as it seems to directly address the issues I've seen. However, I'm not really sure on how to proceed because the DWC_OTG driver is not GPL code Oops? if that wa the case you could not use (and distribute) this code in a Linux context at all. while the EHCI code I'd like to use is. Therefore, I don't believe that I can port the Enhanced Transaction Translation routine into the DWC_OTG driver without violating both the GPL and Synopsis's own driver. What makes you think so? The Synopsis dwc_otg driver license does not seem to be in conflict to the GPL, if you ask me (but then, I am not a layer). When we worked on this, we were assured that the use of this driver source in the context of GPLed software like the Linux kernel (or U-Boot) was not considered an issue by Synopsis. Does anyone have a suggestion on how to proceed? We have been doing some work on the DWC drivers in the past, fixing a number of issues. [We never attempted to psuh any of this into mainline as the Synopsis drivers are - in our opinion - not avcceptable for mainline but require more or less a rewrite from scratch. But you can find all this stuff in our linux-2.6-denx repo.] I recommend you give a try to our latest stable branch. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What is research but a blind date with knowledge? -- Will Harvey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [POWERPC] add U-Boot bootcount driver.
Dear Vitaly Bordug,
repl: bad addresses:
linuxppc-...@ozlabs.org linuxppc-...@ozlabs.org -- junk after
lo...@domain ()
In message 20091216024730.455b9...@vitb-lp you wrote:
From: Heiko Schocher h...@denx.de
This driver provides (read/write) access to the
U-Boot bootcounter via PROC FS or sysFS.
in u-boot, it uses a 8 byte mem area (it must hold the value over a
soft reset of course), for storing a bootcounter (it counts many soft
resets are done, on hard reset it starts with 0). If the bootcountvalue
exceeds the value in the env variable bootlimit, and alternative
bootcmd stored in the env variable altbootcmd is run.
The bootcountregister gets configured via DTS.
for example on the mgsuvd board:
bootco...@0x3eb0 {
device_type = bootcount;
compatible = uboot,bootcount;
reg = 0x3eb0 0x08;
};
This driver is tested on the mgcoge(82xx) and mgsuvd(8xx) board.
Signed-off-by: Heiko Schocher h...@denx.de
Signed-off-by: Wolfgang Denk w...@denx.de
Signed-off-by: Vitaly Bordyug v...@kernel.crashing.org
I think it would be good if the text of the commit message could be
reworked by a native English speaker.
Regarding the subject: it is probably important to point out that this
driver implements the Linux kernel half of the boot count feature -
the boot counter can only be reset after it is clear that the
application has been started and is running correctly, which usually
can only be determined by the application code itself. Thus the reset
of the boot counter must be done by application code, which thus needs
an appropriate driver.
I think there is no reason not to have this in mainline. Thoughts? And
I'm not sure what is right direction to push this - it's representation
of u-boot feature in fact, pretty useful tho.
It's not only useful, it's actually a required feature by the Carrier
Grade Linux Requirements Definition; see for example document Carrier
Grade Linux Requirements Definition Overview V3.0 at
https://www.linux-foundation.org/images/1/1a/Cgl_req_def_overview_30.pdf
Page 49:
ID PLT.4.0 (2.3 in v1.1)Boot Cycle Detection
Description: OSDL CGL specifies that carrier grade Linux
shall provide support for detecting a repeating reboot cycle
due to recurring failures and going to an offline state if
this occurs.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I read part of it all the way through.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc: Move VMX and VSX asm code to vector.S
Dear Benjamin Herrenschmidt, In message 20090603071751.af006dd...@ozlabs.org you wrote: Currently, load_up_altivec and give_up_altivec are duplicated in 32-bit and 64-bit. This creates a common implementation that is moved away from head_32.S, head_64.S and misc_64.S and into vector.S, using the same macros we already use for our common implementation of load_up_fpu. I also moved the VSX code over to vector.S though in that case I didn't make it build on 32-bit (yet). It seems this commit broke ALTIVEC-enablked 32 bit systems. For example, when trying to build 86xx/mpc8641_hpcn_defconfig I get: arch/powerpc/kernel/vector.S: Assembler messages: arch/powerpc/kernel/vector.S:61: Error: Unrecognized opcode: `cmpdi' make[1]: *** [arch/powerpc/kernel/vector.o] Error 1 Segher suggests to s/cmpdi/cmplwi/ which indeed seems to work (atleast it allows me to build the kernel image). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Wherever you go...There you are.- Buckaroo Banzai ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: TQM5200 + SM501 FB
Dear Rolf Offermanns, In message f5b2e7ae-a0c5-4d9b-af8f-3158b94d6...@sysgo.com you wrote: Thanks Wolfgang, I will try it on monday. What needs to be done to get this into mainline? Modify the sm501 stuff for fdt and extend the tqm5200.dts file with the sm501 resources? Right, especially the OF bindings in the SM501 driver and the device tree entries are still missing. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de He'd been wrong, there _was_ a light at the end of the tunnel, and it was a flamethrower. - Terry Pratchett, _Mort_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: TQM5200 + SM501 FB
Dear Rolf Offermanns,
In message 4b191b54.6030...@sysgo.com you wrote:
does anyone has a working SM501 framebuffer on the STK5200 board? The
board itself works fine on the 2.6.32 kernel.
This is a pretty well supported configuration.
I got a patch from TQ which used to work around 2.6.24 but it seems with
the unification of the simple mpc5200 boards the sm501 support got lost.
Don't expect any real support from TQ on this; so far they never
spent any efforts on the arch/powerpc port of the TQM5200.
I toyed around with the patch a bit and I got the driver to probe and
initialize the chip, but I don't get an output on the crt port and an
open() on /dev/fb0 or /dev/fb1 fails with no device.
Did you check if you eventually have forgotten to enable Framebuffer
console in your kernel configuration? Make sure to set:
Device Drivers ---
Character devices ---
[*] Virtual terminal
[*] Support for console on virtual terminal (NEW)
...
Multifunction device drivers ---
* Support for Silicon Motion SM501
...
Graphics support ---
* Support for frame buffer devices ---
[*] Framebuffer foreign endianness support ---
Choice endianness support (Support for Big- and Little-Endian
framebuffers) ---
...
* Silicon Motion SM501 framebuffer support
...
Console display driver support ---
[ ] VGA text console (! disable VGA text console!)
* Framebuffer Console support
Please find attached below a patch which fixes some issues (but we
don't consider it clean enough for inclusion into mainline yet), and a
known to be working config file. [Kudos to Anatolij for providing
this.]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
What was sliced bread the greatest thing since?
From e503a4524ac714f0336ab0a7c02f92ae488e4940 Mon Sep 17 00:00:00 2001
From: Anatolij Gustschin agust@denx.de
Date: Tue, 7 Oct 2009 14:45:16 +0200
Subject: [PATCH] sm501: support SM501 on TQM5200
Signed-off-by: Anatolij Gustschin agust@denx.de
---
drivers/mfd/sm501.c | 40
drivers/video/sm501fb.c | 12 +++-
2 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
index 0cc5eef..970fa89 100644
--- a/drivers/mfd/sm501.c
+++ b/drivers/mfd/sm501.c
@@ -27,6 +27,13 @@
#include asm/io.h
+#if defined(CONFIG_PPC_MPC52xx)
+#undef readl
+#undef writel
+#define readl(addr) __do_readl_be((addr))
+#define writel(val, addr) __do_writel_be((val), (addr))
+#endif
+
struct sm501_device {
struct list_head list;
struct platform_device pdev;
@@ -1378,12 +1385,14 @@ static int __devinit sm501_init_dev(struct sm501_devdata *sm)
sm501_register_gpio(sm);
}
+#if !defined(CONFIG_PPC_MPC52xx) /* prevent crash on tqm5200 */
if (pdata-gpio_i2c != NULL pdata-gpio_i2c_nr 0) {
if (!sm501_gpio_isregistered(sm))
dev_err(sm-dev, no gpio available for i2c gpio.\n);
else
sm501_register_gpio_i2c(sm, pdata);
}
+#endif
ret = sm501_check_clocks(sm);
if (ret) {
@@ -1417,7 +1426,9 @@ static int __devinit sm501_plat_probe(struct platform_device *dev)
ret = platform_get_irq(dev, 0);
if (ret 0) {
dev_err(dev-dev, failed to get irq resource\n);
+#if !defined(CONFIG_PPC_MPC52xx) /* we do not need irq on tqm5200 for fbdev */
goto err_res;
+#endif
}
sm-irq = ret;
@@ -1748,8 +1759,37 @@ static struct platform_driver sm501_plat_driver = {
.resume = sm501_plat_resume,
};
+#if defined(CONFIG_PPC_MPC52xx)
+/* define sm501 resources on tqm5200 */
+#define SM501_FB_BASE 0xe000
+#define SM501_FB_SIZE 0x0080
+#define SM501_IO_BASE 0xe3e0
+#define SM501_IO_SIZE 0x0020
+#define SM501_FB_END ((SM501_FB_BASE) + (SM501_FB_SIZE) - 1)
+#define SM501_IO_END ((SM501_IO_BASE) + (SM501_IO_SIZE) - 1)
+
+static struct resource sm501_device0_resources[] = {
+ [0] = {.start = SM501_FB_BASE, .end = SM501_FB_END, .flags = IORESOURCE_MEM,},
+ [1] = {.start = SM501_IO_BASE, .end = SM501_IO_END, .flags = IORESOURCE_MEM,},
+};
+
+static struct platform_device sm501_device0 = {
+ .name = sm501,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(sm501_device0_resources),
+ .resource = sm501_device0_resources,
+};
+
+static struct platform_device *sm501_mfd_devices[] __initdata = {
+ sm501_device0,
+};
+#endif
+
static int __init sm501_base_init(void)
{
+#if defined(CONFIG_PPC_MPC52xx)
+ platform_add_devices(sm501_mfd_devices, ARRAY_SIZE(sm501_mfd_devices));
+#endif
platform_driver_register(sm501_plat_driver);
return pci_register_driver(sm501_pci_driver);
}
diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
index 924d794..6b65ecd 100644
--- a/drivers/video/sm501fb.c
+++ b/drivers/video/sm501fb.c
@@ -43,6 +43,13
Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
);
iounmap(ioc-memmap);
if (r != -5)
pci_release_selected_regions(pdev, ioc-bars);
@@ -2547,6 +2556,11 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
ioc-pci_irq = -1;
}
+ if (ioc-portmap != NULL) {
+ iounmap(ioc-portmap);
+ ioc-portmap = NULL;
+ }
+
if (ioc-memmap != NULL) {
iounmap(ioc-memmap);
ioc-memmap = NULL;
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index dff048c..17826b3 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -584,8 +584,8 @@ typedef struct _MPT_ADAPTER
SYSIF_REGS __iomem *chip; /* == c8817000 (mmap) */
SYSIF_REGS __iomem *pio_chip; /* Programmed IO (downloadboot)
*/
u8 bus_type;
- u32 mem_phys; /* == f402 (mmap) */
- u32 pio_mem_phys; /* Programmed IO (downloadboot)
*/
+ resource_size_t mem_phys; /* == f402 (mmap) */
+ resource_size_t pio_mem_phys; /* Programmed IO (downloadboot)
*/
int mem_size; /* mmap memory size */
int number_of_buses;
int devices_per_bus;
@@ -635,6 +635,7 @@ typedef struct _MPT_ADAPTER
int bars; /* bitmask of BAR's that must
be configured */
int msi_enable;
u8 __iomem *memmap;/* mmap address */
+ u8 __iomem *portmap; /* mmap address */
struct Scsi_Host*sh;/* Scsi Host pointer */
SpiCfgData spi_data; /* Scsi config. data */
RaidCfgData raid_data; /* Raid config. data */
--
1.5.6.1
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I haven't lost my mind - it's backed up on tape somewhere.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI interrupt question
Dear David Hawkins, In message 4b1816f9.1020...@ovro.caltech.edu you wrote: Yep. It might require enabling a PCI subsystem in U-Boot. I recall playing with a Yosemite board and a PCI card, but I forget whether I had to do anything to enable PCI configuration space setup. Post a question to the U-Boot list. PCI is enabled by default on the Canyonlands board, both in U-Boot and Linux. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In the long run, every program becomes rococo, and then rubble. - Alan Perlis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC5121ADS PowerVR MBX driver on 2.6.31 kernel?
Dear Cristian Axenie, In message 9c789a000912021004l5dda0ee8r77a21764e035f...@mail.gmail.com you wrote: I would like to know if there is someone that tested the MBX driver for the PowerVR graphic chip in MPC5121 ? It seems that on kernel 2.6.21 works fine but it fails on 2.6.31 ! You probably have to rebuild it from the source code for this new kernel version. I'm using wrlinux as the build environment ! Maybe you ask WRS to provide matching binaries, then? [Note that woever provides the binaries also has to provide the sources; the kernel is GPL after all...] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If the car industry behaved like the computer industry over the last 30 years, a Rolls-Royce would cost $5, get 300 miles per gallon, and blow up once a year killing all passengers inside. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: EP440XS board boot problem(Note:similart to Sequoia)
Dear Allan Wang, In message 880531.39933...@web52905.mail.re2.yahoo.com you wrote: Thank you for your help. My answer to your questions are between the lines. Attached is the dts file I use. No, there is no attachment. Which exact version of U-Boot are you running on this board? = version U-Boot 1.1.6 (Oct 25 2009 - 13:26:41) Um... why don't you update? This is really historic stuff... What is your exact boot command? I tftp the cuImage to address 0x20 and bootm to boot. Which boot arguments do you pass to the kernel? bootargs=$(bootargs) console=ttyS0,$(baudrate) Please provide complete answers, and not only the snippets that seem important to you. For example, what is the $(bootargs) above? Maybe you provide a full boot log right from reset/power on, including the output of the printenv command on your system. The u-boot sets it to 115.2k. the dts file is set to 115.2k. Here is the bo ot parameter: baudrate=115200 Arghhh.. Please provide the actual output fdrom your system, not just some parts you copy. What does your device tree look like? I attached my dts file. No, it's missing. 2. It pakics when mounting the root file system(NFS): (gdb) bt #0 panic (fmt=0xc0290e94 VFS: Unable to mount root fs on %s) So what is the %s argument here? Which sort of root file system are you trying to mount - NFS, ramdisk, UBIFS, ... ? I try to use NFS for the root file system. Then you can also run a packet sniffer (like wireshark) to see if any NFS requests actually get sent to the targte, resp. where it stops). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Romulan women are not like Vulcan females. We are not dedicated to pure logic and the sterility of non-emotion. -- Romulan Commander, The Enterprise Incident, stardate 5027.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC5121ADS PowerVR MBX driver on 2.6.31 kernel?
Dear Chen Hongjun-R66092, In message 3a45394fd742fa419b760bb8d398f9ede65...@zch01exm26.fsl.freescale.net you wrote: The released binary MBX driver is based on kernel 2.6.24, not on 2.6.31. It is a GPL violation that there is no source code available for it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Save energy: Drive a smaller shell. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: EP440XS board boot problem(Note:similart to Sequoia)
Dear Allan Wang, In message 401793.31718...@web52903.mail.re2.yahoo.com you wrote: I am new to the list. I am still newbie to embedded linux. I have bought an ep440xs board which is similar to sequoia board. u-boot is working. I am trying to make it run linux. I have the following problems and need your help. Thank you very much: Which exact version of U-Boot are you running on this board? I guess this is a out-of-tree port, i. e. not part of the mainline U-Boot repository - so are you sure that device tree support is enabled in your version of U-Boot? I am using linux kernel 2.6.30.4. I encounter 2 problems: 1. After console_init() is called inside start_kernel(), the console starts printing garbage like: Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0x1ef600300 (irq = 16) is a 16550A ������������������������������ ... What is your exact boot command? Which boot arguments do you pass to the kernel? What is ytour console baud rate in U-Boot, and what sort of console= boot argument do you pass to the Linux kernel? What does your device tree look like? 2. It pakics when mounting the root file system(NFS): (gdb) bt #0 panic (fmt=0xc0290e94 VFS: Unable to mount root fs on %s) So what is the %s argument here? Which sort of root file system are you trying to mount - NFS, ramdisk, UBIFS, ... ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de He only drinks when he gets depressed. Why does he get depressed? Sometimes it's because he hasn't had a drink. - Terry Pratchett, _Men at Arms_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: enabling USB Host controller on ppc405ex based board
Dear Jignesh Patel, please do not post the same messages several times to several mailing lists. In message d7c6597e47cdad4ba48ee3d2b03b385102e7c3c...@vmbx113.ihostexchange.net you wrote: We have Kilauea based board using ppc405ex. it has usb-otg tranciever chip on it. I am trying to enable USB Host Controller Driver in linux kernel (version DENX 2.6.27-stable). For this to be enabled, I also have to Please note that the Synopsys USB driver in our tree has not been maintained for a long time. Over time, it detoriated. Only recently we have put some more efforts into it to at least make it work again. It still is in a pretty poor state, which is the main reason we never attempted to push this upstream. [In my opinion it needs to be rewritten from scratch.] For the relevant changes please see for example http://git.denx.de/?p=linux-2.6-denx.git;a=commit;h=126bae384eacef18bcae302024d49e25a06cb648 My questions are: 1. Why is PCI config required for USB Host Controller options to be enabled in kernel config? 2. What needs to be done to boot our board with PCI USB enabled kernel? Please use a more recent kernel version - either use top of tree from the master branch of our repository, or a recent version from our 2.6.30.y or 2.6.31.y stable branches, i. e at least DENX-v2.6.30.3 or DENX-v2.6.31.4 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. - Frederick Brooks Jr., The Mythical Man Month ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SPRN_SVR for MPC5121e?
Dear Wolfram Sang, In message 20091028152324.gc3...@pengutronix.de you wrote: my MPC5121e (Rev2) has PVR/SVR: 0x8086_2010/0x8018_0020 (as mentioned in the manual) ... Does someone here have a Rev1 and can ultimately confirm and/or supply the complete PVR/SVR for Rev1? Couldn't find any hint neither in the manual nor in the web. We saw PVR/SVR = 0x80862010 / 0x80180010 for MPC5121 and PVR/SVR = 0x80862010 / 0x80180030 for MPC5123 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Quantum particles: The dreams that stuff is made of. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/3] powerpc/fsl: 85xx: document cache-sram
Dear Vivek Mahajan, In message 1256129459-10685-2-git-send-email-vivek.maha...@freescale.com you wrote: Adds documentation for Freescale's QorIQ based cache-sram as under:- * How to enable it from a low level driver * How to set its size ... +The size of the above cache SRAM memory window is passed via the +kernel command line as cache-sram-size= Would it not make more sense to configure this property through the device tree? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. - Howard Aiken ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mixing hard and soft floating point?
Dear Joakim Tjernlund, In message ofefbde7c9.da9d5b8b-onc1257653.003e3dc6-c1257653.003f0...@transmode.se you wrote: If the application is really using FP instructions a lot, then there is a huge difference between using soft-float and MATH_EMU; I remember test cases where soft-float was faster by factors of 500...1000. Ouch, I had no idea that it could be that much. Well, consider really simple operations, like FP add or similar, and compare the library code for the soft-FP implementationagainst the cost for a trap into the kernel. Or even worse - a consider simple assignment (float x, foo; x = foo); with soft-float: lis 9,x...@ha; stw 3,x...@l(9) = 2 instructions, with MATH_EMU lis 9,x...@ha; stfs 1,x...@l(9) = 1 insn plus a kernel trap. For real numbers, run a benchmark that models your real use case. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Little known fact about Middle Earth: The Hobbits had a very sophi- sticated computer network! It was a Tolkien Ring... ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mixing hard and soft floating point?
Dear Joakim Tjernlund, In message ofc920e57f.dfabc29f-onc1257652.00421e11-c1257652.00434...@transmode.se you wrote: Anyone tried mixing hard and soft FP in on soft float CPU such as 83xx? Hm... most 83xx have a FPU. Been trying to figure out if this is a good idea or not. Any combinations that will or won't work? What exactly do you mean by mixing? You cannot (at least not with any reasonable effort) mix hard and soft FP in the same application / linked object. And it would be pretty difficult to setup separate libraries for and all that stuff for both hard and soft FP binaries in one system. I doubt if such a setup makes sense at all. Generally I got soft FP in all system libs but there might be an binary application which will use hard FP. Recompile and relink it with soft-fp as well. Or ask the provider to do that. Is the MATH_EMU option in the kernel reliable(for 8xx too)? It's reliable enough to install and run standard distributions like Debian, Ubuntu, or Fedora, but I have to admit that we haven't stress tested any special FP test suites in such an environment. In everyday use I didn't see any real issues, though. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If I can have honesty, it's easier to overlook mistakes. -- Kirk, Space Seed, stardate 3141.9 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mixing hard and soft floating point?
Dear Joakim Tjernlund, In message ofec00b9fb.b03aa854-onc1257652.00644350-c1257652.00651...@transmode.se you wrote: Recompile and relink it with soft-fp as well. Or ask the provider to do that. That is what I am trying do/find out. The supplier claims that it should not be a problem and is ATM unwilling to recompile the app/libs. I am not convinced won't cause problems, not to mention performance degradation. If the application is really using FP instructions a lot, then there is a huge difference between using soft-float and MATH_EMU; I remember test cases where soft-float was faster by factors of 500...1000. OK, but then you don't mix some libs/apps with soft and other apps/libs with hard FP? No, we never tried that. Sounds scary to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The connection between the language in which we think/program and the problems and solutions we can imagine is very close. For this reason restricting language features with the intent of eliminating pro- grammer errors is at best dangerous. - Bjarne Stroustrup in The C++ Programming Language ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC5121 CAN and USB
Dear =?ISO-8859-1?Q?K=E1ri_Dav=ED=F0sson?=, In message 4ad70927.3030...@marel.com you wrote: The kernel from the BSP on Freescale site is crashing on the CAN in my case (might be a hardware bug). I don;t think so. There are some problems in this code, for example the clocks seem to be wrong. Not toi menthin that the whole code is hoplessly old and without chance of ever being merged into mainline. I could not find the source for the kernel in the BSP or on the freescale site. Extracting just the sources from LTIB (without actually building all of it) is indeed not exactly easy. I had not looked at http://git.denx.de/?p=linux-2.6-denx.git;a=shortlog;h=refs/heads/ltib-mpc5121ads-20090602 Be careful. There are several branches that are intended for reference only, or reflect work in progress. These are usually not intended for use real use in a project: The ltib-mpc5121ads-20090602 branch reflects the exact state of the kernel contained in the LTIB with this name (dated July 2009, despite the name; based at 2.6.24.6, i. e. 7+ kernel versions behind). The mpc512x branch contains a much smaller subset of drivers, but is based on a more recent kernel tree (2.6.31-rc5) and is the base of our (currently dozing) attempts to push this code into mainline. I am now in the progress of cloning the linux-mpc512x git from denx and building from it. Hopefully that will help me. Do not do this. This old repository was intended for co-operation with John Rigby, when he was still working for Freescale. It is a dead end and totally unsupported. Guess I should remove it. Indeed. Removed now. Sorry for the confusion. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Anyone who knows history, particularly the history of Europe, will, I think, recognize that the domination of education or of government by any one particular religious faith is never a happy arrangement for the people. - Eleanor Roosevelt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux booting fails on ppc440x5 with SRAM
Dear Vineeth _, In message a9b543570910090320t1444f8f1qf4c8ab7dbbef6...@mail.gmail.com you wrote: We ported the uboot Memory test and tested the 15MB ram and it was successful.interestingly we have only 16MB SRAM in our board.We used 1 Such a memory test means nothing. The only thing you can learn from it is that basic read and write accesses are working. You don;t get any information about the behaviour for burst mode accesses from such a test. See the FAQ at http://www.denx.de/wiki/view/DULG/LinuxCrashesRandomly and at http://www.denx.de/wiki/DULG/UBootCrashAfterRelocation Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I mean, I . . . think to understand you, I just don't know what you are saying ...- Terry Pratchett, _Soul Music_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: LITE5200 configuration
Dear FIXED-TERM Seeh Thomas (BEG/EMS1), In message 6e9d235b18ce694399d781f05d9c42e79f0c2...@si-mbx11.de.bosch.com you wrote: I'll try to run a 2.6.31-rc7 kernel on my Lite5200 board. Is this really a Lite5200, or is it a Lite5200B? Hint: if U-Boot prints something like CPU: MPC5200B v2.2, Core v1.4 then its a 5200B, and thus a Lite5200 board. For the device tree I use lite5200.dts and compiled it simply with make ARCH=powerpc CROSS_COMPILE=ppc_6xx- lite5200.dtb For a Lite5200B you should use the lite5200b device tree. But I'm not sure what configuration for the kernel I should choose. There is no lite5200_defconfig only one for the lite5200b. Rigth. Because there are virtually no lite5200 boards out there. I tried it with mpc5200_defconfig and lite5200b_defconfig, but I'm not sure which is the right way. Both will work. On a Lite5200 board I would use lite5200b_defconfig, though. For compiling the kernel I use: make ARCH=powerpc CROSS_COMPILE=ppc_6xx- CONFIG_FILE That's: make ARCH=powerpc CROSS_COMPILE=ppc_6xx- mrproper make ARCH=powerpc CROSS_COMPILE=ppc_6xx- 52xx/lite5200b_defconfig make ARCH=powerpc CROSS_COMPILE=ppc_6xx- uImage make ARCH=powerpc CROSS_COMPILE=ppc_6xx- modules make ARCH=powerpc CROSS_COMPILE=ppc_6xx- modules_install I use U-Boot 2009.06, with the following settings for bootup: Looks as if you have a Rev. B CPU with the wrong device tree. Unfortunaltey you omit the interesting part (i. e. the U-Boot boot message) which would contain this important piece of information. --_000_6E9D235B18CE694399D781F05D9C42E79F0C2C12SIMBX11deboschc_ Content-Type: text/html; charsetiso-8859-1 Content-Transfer-Encoding: quoted-printable And *please* do not post HTML to mailing lists. Never ever do that. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If I ever needed a brain transplant, I'd choose a teenager's because I'd want a brain that had never been used. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [SATA] Does SATA work with kernel v2.6.25.7?
Dear Olivier Croset, In message aa253ff7c15741bcae4b5d4b4fff1...@labo5 you wrote: While browsing the web, I found the following message with the same kind of errors: http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-03/msg08159.html It is said that the sata is only supported up to 2.6.25.7. Is it true for all PowerPCs or only for 460EX CPU? This messages is explicitly about (and only about) the AMCC 460EX Canyonlands board and the Synopsys DesignWare Cores (DWC) SATA driver used on this processor. This has nothing to do with your poblems with a SIL controller. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When all is said and done, more is said than done. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sequoia: The final kernel image would overwrite the device tree
Dear Ben, In message 1249678991.10143.1.ca...@pasglop you wrote: My experience, however, with a Canyonlands board, is that uBoot has a bug that makes it always allocate the device-tree below 8M and clash with the kernel when it gets too big. I think Stefan fixed that recently, you may need to rebuild your uboot, I'll let him tell you the details about the fix. Right. These are the relevant commits; they went into mainline some time ago: commit 27dd5f8e1062684f1ba685760409d9b2ab6691bf Author: Stefan Roese s...@denx.de Date: Tue Jul 28 10:56:03 2009 +0200 ppc4xx: amcc: Move kernel_addr_r etc to higher locations ( 16MB) This patch moves the load addresses for kernel, fdt and ramdisk to higher addresses (= 16MB). This enables booting of bigger kernel images (e.g. lockdep enabled). Signed-off-by: Stefan Roese s...@denx.de commit 6942efc2be1b90054fa4afa5cda7023469fe08b9 Author: Stefan Roese s...@denx.de Date: Tue Jul 28 10:50:32 2009 +0200 ppc4xx: amcc: Set CONFIG_SYS_BOOTMAPSZ to 16MB for big kernels This patch changes CONFIG_SYS_BOOTMAPSZ from 8MB to 16MB which is the initial TLB on 40x PPC's in the Linux kernel. With this change even bigger Linux kernels ( 8MB) can be booted. This patch also sets CONFIG_SYS_BOOTM_LEN to 16MB (default 8MB) to enable decompression of bigger images. Signed-off-by: Stefan Roese s...@denx.de Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Every solution breeds new problems. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: image/wrapper script questions
Dear Eddie Dawydiuk, In message 4a6ddf80@embeddedarm.com you wrote: I'm working on a custom board using an AMCC 440EP that is using a proprietary bootloader(optimized for fast boot time). Currently our bootloader loads a simpleImage.initrd into RAM and jumps into it. I originally chose to use a simpleImage with an initial ramdisk embedded because it was the simplest solution to debug the hardware and get a kernel and initial ramdisk running for development. For production I would prefer to put the initial ramdisk on it's Hm... isn't that an oxymoron? Trying to optimize for speed on one hand, and using an initrd which is one of the slowest ways to boot on the other hand? Thanks for any suggestions :) Use another file system (and another fstype) and separate it from the kernel image. See also http://www.denx.de/wiki/view/DULG/RootFileSystemSelection Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Computers are not intelligent. They only think they are. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PPCboot and latest kernel
Dear vijay sharma, In message e571380d0907191136j37d341d7k514f46396a38a...@mail.gmail.com you wrote: I have been woking on upgrading an embedded system based on MPC8241 from 2.4.17 linux to 2.6.30 kernel. Wow, that's a big leap... You should also consider to update to the latest version of U-Boot; the time when it was still called PPCBoot is long, long past. I am currently struck one point. Here is the console output where I am struck: = cpboot bootm ## Booting image at 0800 ... Image Name: Linux-2.6.30 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:21729342 Bytes = 21220 kB = 20 MB Load Address: 0190 Entry Point: 01900570 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Memory - 0x0 0x1000 (256MB) CPU clock-frequency - 0xbebc1fe (200MHz) CPU timebase-frequency - 0x17d783f (25MHz) CPU bus-frequency - 0x5f5e0ff (100MHz) zImage starting: loaded at 0x0190 (sp: 0x0fdc3a08) Allocating 0x165ca04 bytes for kernel ... gunzipping (0x - 0x0190c000:0x02f58efc)...done 0x1637b54 bytes You loaded the image at 0190, but the uncompr4essed image extends until 02f58efc, i. e. there is a good chance that you will overwrite parts of the still uncompressed image. Linux/PowerPC load: Finalizing device tree... flat tree at 0x2f65300 == Beyond this point no output is available. Your device tree might be wrong, too. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any sufficiently advanced bug is indistinguishable from a feature. - Rich Kulawiec ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Simple question about powerpc asm.
Dear Valentine, In message 4a61a48d.8060...@ru.mvista.com you wrote: PowerPC instructions are 32-bit long. So, there are only 16 bits available within the instruction for constant values. Since address can be up to 64 bits, we have to load it a piece at a time. The @ within the assembler instruct it to give a specially-processed form of a symbol value: @highest -- refers to bits 48-63 of a constant @higher -- refers to bits 32-47 of a constant @h -- refers to bits 16-31 of a constant @l -- refers to bits 0-15 of a constant Actually these bit numbers are wrong, as bit 0 is the MSB for PowerPC ;-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Emotions are alien to me. I'm a scientist. -- Spock, This Side of Paradise, stardate 3417.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v4] fs_enet/mii-fec.c: fix MII speed calculation
Dear Grant Likely, In message fa686aa40907161544je92317dy7abea6819746...@mail.gmail.com you wrote: I assume this is tested. I have not tested this on my board, and I've It was tested, but as it turns out not quite well :-( got one question below, but otherwise I think I can say ... The calculation has changed here for non mpc5121 users. Shouldn't the clock = ppc_proc_freq; line above be clock = ppc_proc_freq / 2;? Or was this also a bug in the original driver? You are right. That's a bug in the new code. Fixed in next version of the patch. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Swap read error. You lose your mind. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2 v2] MPC52xx FEC: be more conservative when setting MII_SPEED register
Dear Grant Likely, In message fa686aa40907161548n1658afaei8dce2d8932220...@mail.gmail.com you wrote: Mostly good. One comment below. When it's resolved, feel free to add my acked-by line. Thanks for getting this done. ... Just thought of something. If it cannot find the clock, then wouldn't it be better to just use the maximum divider and print a warning instead of bailing completely? This goes for the other patch as well. Will change this for both patches. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Program maintenance is an entropy-increasing process, and even its most skilfull execution only delays the subsidence of the system into unfixable obsolescence. - Fred Brooks, The Mythical Man Month ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2 v3] MPC52xx FEC: be more conservative when setting MII_SPEED register
This patch adds error checking and prevents clobbering unrelated bits
(reserved bits or the DIS_PREAMBLE bit) when writing the MII_SPEED
register on MPC52xx systems.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: net...@vger.kernel.org
---
v3: - use maximum divider in case MPC512x IPS clock is unknown
drivers/net/fec_mpc52xx.c |2 +-
drivers/net/fec_mpc52xx_phy.c | 23 ---
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cc78633..b69d440 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -639,7 +639,7 @@ static void mpc52xx_fec_hw_init(struct net_device *dev)
/* set phy speed.
* this can't be done in phy driver, since it needs to be called
* before fec stuff (even on resume) */
- out_be32(fec-mii_speed, priv-mdio_speed);
+ clrsetbits_be32(fec-mii_speed, 0x7E, priv-mdio_speed);
}
/**
diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.c
index 31e6d62..d3537e1 100644
--- a/drivers/net/fec_mpc52xx_phy.c
+++ b/drivers/net/fec_mpc52xx_phy.c
@@ -70,7 +70,7 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of,
struct mpc52xx_fec_mdio_priv *priv;
struct resource res = {};
int err;
- int i;
+ int i, clock, speed;
bus = mdiobus_alloc();
if (bus == NULL)
@@ -105,8 +105,25 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of,
dev_set_drvdata(dev, bus);
/* set MII speed */
- out_be32(priv-regs-mii_speed,
- ((mpc5xxx_get_bus_frequency(of-node) 20) / 5) 1);
+ clock = mpc5xxx_get_bus_frequency(of-node);
+ if (!clock) {
+ /* Use maximum divider if clock is unknown */
+ dev_err(of-dev, could not determine IPB clock\n);
+ clock = 0x3F * 500;
+ }
+
+ /*
+* Scale for a MII clock = 2.5 MHz
+* Note that only 6 bits (25:30) are available for MII speed.
+*/
+ speed = (clock + 499) / 500;
+ if (speed 0x3F) {
+ speed = 0x3F;
+ dev_err(of-dev, MII clock (%d Hz) exceeds max (2.5 MHz)\n,
+ clock / speed);
+ }
+
+ clrsetbits_be32(priv-regs-mii_speed, 0x7E, speed 1);
err = of_mdiobus_register(bus, np);
if (err)
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2 v5] fs_enet/mii-fec.c: fix MII speed calculation
The MII speed calculation was based on the CPU clock (ppc_proc_freq),
but for MPC512x we must use the bus clock instead.
This patch makes it use the correct clock and makes sure we don't
clobber reserved bits in the MII_SPEED register.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: net...@vger.kernel.org
---
v5: - fix divider so we really use 2.5 MHz (instead of 1.25)
- use maximum divider in case MPC512x IPS clock is unknown
drivers/net/fs_enet/mii-fec.c | 37 +
1 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
index 75a0999..5176986 100644
--- a/drivers/net/fs_enet/mii-fec.c
+++ b/drivers/net/fs_enet/mii-fec.c
@@ -36,6 +36,7 @@
#include asm/pgtable.h
#include asm/irq.h
#include asm/uaccess.h
+#include asm/mpc5xxx.h
#include fs_enet.h
#include fec.h
@@ -103,11 +104,11 @@ static int fs_enet_fec_mii_reset(struct mii_bus *bus)
static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct resource res;
struct mii_bus *new_bus;
struct fec_info *fec;
- int ret = -ENOMEM, i;
+ int (*get_bus_freq)(struct device_node *) = match-data;
+ int ret = -ENOMEM, clock, speed;
new_bus = mdiobus_alloc();
if (!new_bus)
@@ -133,13 +134,35 @@ static int __devinit fs_enet_mdio_probe(struct of_device
*ofdev,
if (!fec-fecp)
goto out_fec;
- fec-mii_speed = ((ppc_proc_freq + 499) / 500) 1;
+ if (get_bus_freq) {
+ clock = get_bus_freq(ofdev-node);
+ if (!clock) {
+ /* Use maximum divider if clock is unknown */
+ dev_warn(ofdev-dev, could not determine IPS
clock\n);
+ clock = 0x3F * 500;
+ }
+ } else
+ clock = ppc_proc_freq;
+
+ /*
+* Scale for a MII clock = 2.5 MHz
+* Note that only 6 bits (25:30) are available for MII speed.
+*/
+ speed = (clock + 499) / 500;
+ if (speed 0x3F) {
+ speed = 0x3F;
+ dev_err(ofdev-dev,
+ MII clock (%d Hz) exceeds max (2.5 MHz)\n,
+ clock / speed);
+ }
+
+ fec-mii_speed = speed 1;
setbits32(fec-fecp-fec_r_cntrl, FEC_RCNTRL_MII_MODE);
setbits32(fec-fecp-fec_ecntrl, FEC_ECNTRL_PINMUX |
FEC_ECNTRL_ETHER_EN);
out_be32(fec-fecp-fec_ievent, FEC_ENET_MII);
- out_be32(fec-fecp-fec_mii_speed, fec-mii_speed);
+ clrsetbits_be32(fec-fecp-fec_mii_speed, 0x7E, fec-mii_speed);
new_bus-phy_mask = ~0;
new_bus-irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
@@ -188,6 +211,12 @@ static struct of_device_id fs_enet_mdio_fec_match[] = {
{
.compatible = fsl,pq1-fec-mdio,
},
+#if defined(CONFIG_PPC_MPC512x)
+ {
+ .compatible = fsl,mpc5121-fec-mdio,
+ .data = mpc5xxx_get_bus_frequency,
+ },
+#endif
{},
};
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v4] fs_enet/mii-fec.c: fix MII speed calculation
Dear Wolfram Sang,
In message 20090717093307.gb3...@pengutronix.de you wrote:
...
@@ -188,6 +209,12 @@ static struct of_device_id fs_enet_mdio_fec_match[] = {
{
.compatible = fsl,pq1-fec-mdio,
},
+#if defined(CONFIG_PPC_MPC512x)
+ {
+ .compatible = fsl,mpc5121-fec-mdio,
+ .data = mpc5xxx_get_bus_frequency,
+ },
+#endif
Grepping through 'drivers/*' I see that #ifdefing compatible-entries is highly
uncommon (just 3 hits). I think a guideline would be useful. Most people like
to avoid #ifdefs at any cost, while I personally think it doesn't spoil
readability too much here. Other opinions?
An older version of the patch tried to hide the ifdef in a 512x
specific header, so at least common code would remain clean, but I
agree with Grant that this current version looks cleaner globally.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You can have my Unix system when you pry it from my cold, dead
fingers.- Cal Keegan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2 v2] MPC52xx FEC: be more conservative when setting MII_SPEED register
Dear Wolfram Sang, In message 20090717094725.gc3...@pengutronix.de you wrote: In the probe-function when mdio_speed is set, there is still the old formula used. Wouldn't that be better in sync? Good point. Next version of patch following soon. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Prof:So the American government went to IBM to come up with a data encryption standard and they came up with ... Student: EBCDIC! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
