BDI2000 help
In message b4b98b690605081527u9001aandfd6f54733c2a09d at mail.gmail.com you wrote: The question I have is what type do I select for my MPC8260. As you can see I'm new to this part of the PPC world. I'm usually a bit higher up and someone has already set this up for me. Well, maybe you can come down a bit and start reading the manual that comes with the BDI2000? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken
BDI2000 help
In message b4b98b690605081559u7d03cb73m733a50ac2825fc27 at mail.gmail.com you wrote: The question I have is what type do I select for my MPC8260. As you ... Funny Wolfgang. I did read it but we only have a very outdated version. So it only talks about the MPC8xx/MCP5xx. So it's a bit Ummm... if you want to use the BDI2000 with a MPC8260 processor you need a firmware version for such a CPU. Abatron always ships these with manual included (both on paper copy and on floppy disk). outdated. I couldn't readily find the newer manual. So when all else fails. Ask. :) Before asking, search. You should be able to find http://www.abatron.ch/, and then http://www.abatron.ch/Files/ManGdbCOP-2000C.pdf Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at 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
MPC8540 experience
Hello, Mark! Sorry, for my late reply, I wasn't reading the mailing lists for a while because I am pretty busy with hardware development. Hallo Herr Koller, ich habe heute ihre EMail (http://ozlabs.org/pipermail/linuxppc-embedded/2004-October/015851.html) gelesen. Hatten sie bereits Erfolg? Ich habe ein ?hnliches Problem. Wir beutzen bei uns ebenfalls einen PPC und haben das Problem mit Big und Littel-Endian im XServer. English, please. You are looking for the SM501 graphics controller working on the PCI Bus on the MPC8540 as far as I got your mail. Yes, the last status I got is that the endianess is an issue for the X-server if the SM501 is on PCI. However there are patches for the framebuffer/X driver environment which takes care about the RGBA's somewhere out there. There are also accelerated native X drivers available but I haven't used those. Additionally, we have the option to swap the colors in hardware, just in case anything goes wrong. :-) Have you seen the work done at Denx (www.denx.de) with the MPC5200 and SM501? Yes. But AFAIK they have the SM501 on the Local Bus of the MPC5200 which is a different thing. Check their hardware documentation, if available. Maybe there are more updates in the meanwhile... Updates are very welcome. I will have to investigate that further if I come back to the software layer of my project. Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
Viable PPC platform?
I have a ppc405gpr system with 64M ram and 4Meg flash in a AM29LV320. Is this a viable platform for linux? Can a filesystem (JFFS2?) be put this flash type? -- Lit up like Levy's
Viable PPC platform?
On Tue, May 09, 2006 at 10:38:19AM -0400, geneSmith wrote: I have a ppc405gpr system with 64M ram and 4Meg flash in a AM29LV320. Is this a viable platform for linux? Can a filesystem (JFFS2?) be put this flash type? Yes. (Yes) Yes. -Matt
Viable PPC platform?
On Tue, 09 May 2006 10:38:19 -0400 geneSmith gd.smth at gmail.com wrote: I have a ppc405gpr system with 64M ram and 4Meg flash in a AM29LV320. Is this a viable platform for linux? Can a filesystem (JFFS2?) be put this flash type? I would create an initrd and put every file that doesn't need to be changed persistently into it instead of JFFS2. The reason for this is that if JFFS2 becomes too full (less than 5 free blocks) you may find that writes to it hang. Alex -- Lit up like Levy's ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Viable PPC platform?
On Tue, May 09, 2006 at 05:41:01PM +0100, Alex Zeffertt wrote: On Tue, 09 May 2006 10:38:19 -0400 geneSmith gd.smth at gmail.com wrote: I have a ppc405gpr system with 64M ram and 4Meg flash in a AM29LV320. Is this a viable platform for linux? Can a filesystem (JFFS2?) be put this flash type? I would create an initrd and put every file that doesn't need to be changed persistently into it instead of JFFS2. After many years of doing embedded Linux stuff I still don't understand why people are so fond of initrd. For temporary stuff - tempfs is much better and flexible. For r/o stuff - just make separate MTD partition (cramfs, squashfs) and mount it directly as root. Both options will waste significantly less memory. -- Eugene
IMAP_ADDR on PPC 8xx
Hi All, Thanks for you response, Wolfgang. On Tue, 2006-05-09 at 00:46 +0200, Wolfgang Denk wrote: In message 1147108983.27101.63.camel at excalibur.timesys.com you wrote: In particular, I have an MPC885ADS board running U-Boot 1.1.3 (Apr 19 2005 - 13:39:58). It will boot neither 2.6.15 nor 2.6.16.11. After U-Boot decompresses the kernel, I get no kernel output at all; it just hangs. Probably you forgot to specify a correct console device with your boot arguments. Excellent point, but unfortunately this (at least by itself) didn't help. After some debugging, I think things go awry when the code starts dereferencing IMAP_ADDR as a direct pointer. IMAP_ADDR is defined to be 0xFF00, but the MPC885ADS documentation says that the internal Correct. memory map is supposed to at 0x2200. In addition, when I look at the bd_t pointer from U-Boot, it's saying that 0x2200 is the correct address. No. U-Boot uses 0xFF00. At least the official U-Boot source tree does. I don't know where you got yours from, or who might have broken it. Why is this a problem for us and apparently not for anyone else on this list? Is no one else using U-Boot? Or does everyone else's U-Boot use 0xFF00 instead of 0x2200? Or do I have a different problem Most probably everybody else who uses U-Boot uses a good version with a high mapping. Interesting. Thanks for the info. I'm not certain where this U-Boot came from -- it was already loaded onto the board when the board landed in my lap. I suspect that this U-Boot may have come from Freescale. While reading through the archives, I see that using IMAP_ADDR the way it is currently used is somewhat frowned upon anyway. Is this one of those things that we (the PPC Linux community) should fix the right way once and for all? I'm happy to submit a patch once I understand what the right way is... :-) The memory map requirements of PowerPC systems have been explained many times before, so a little search in the archives, HOWTOs etc. should point you quickly for good description why a low mapping like 0x2200 cannot work. Thanks again for the advice. Interestingly, I gave the wrong address above. It wasn't 0x2200, it was 0x0220 (i.e. even lower!). And yet with the io_remap()'ed global variable patch, 2.6.11.7 does indeed work on this board with this U-Boot Perhaps this works because this particular board only has 8MiB of RAM I'll definitely investigate switching to a U-Boot built from official sources. Interestingly, I ran into a similar problem on a completely different Freescale board about a year ago. We have an MPC8272ADS board that definitely has a Freescale copy of U-Boot and it fails to boot vanilla kernels due to different definitions for the BCSR addresses (which if I recall correctly are within the internal memory map and thus controlled by the IMMR register). At that time, Kumar appealed to the community on this mailing list to figure out the right solution to the discrepancy. I didn't have time to do the right thing, so I merely #ifdef'd out the offending code in the kernel and the problem magically went away (I suspect that the Freescale U-Boot had already initialized things sufficiently that it wasn't strictly _necessary_ for the kernel to re-initialize the same registers (even if it might have been _desired_)). Bottom line: I'm wondering what the Linux PPC community thinks is the correct long term solution to these discrepancies. Should we the community declare Freescale U-Boots are considered harmful; never use them; always use the official U-Boot sources ??? Or should we create a kernel mechanism to automatically adapt to the different U-Boot flavors? In a related vein, as I alluded to in my previous email, there has been previous discussion on this list about the fact that it is frowned upon for device drivers to directly dereference IMAP_ADDR. Instead, I've seen a recommendation that each individual driver perform an io_remap() operation on IMAP_ADDR and save the resulting kernel virtual address in a driver-specific data structure. Is this a universally-accepted viewpoint? Is this something that the community agrees should be fixed and we're just waiting for someone (like me) to volunteer to fix all the drivers? Or are there arguments in favor of keeping the direct IMAP_ADDR dereferences? For example, if each driver performs its own separate io_remap(), doesn't that have potentially negative consequences on the VM system for some PPC implementations (e.g. increased contention for TLB entries)? Are these issues addressed by or otherwise impacted by other ongoing PPC Linux work such as the ppc + ppc64 -- powerpc effort / flat device tree stuff??? Best regards, Wolfgang Denk Thanks!!! Walt Wimer TimeSys Corporation
system hang in early_init
It seems that my PPC405 V2Pro system is hanging in the function early_init, in arch/ppc/kernel/setup.c. Using LEDs, I've been able to determine that the following line seems to be where it dies: memset_io(PTRRELOC(__bss_start), 0, _end - __bss_start); Looking in System.map, I see that __bss_start is 0xC013F000 and _end is 0xC014DA60, with a whole bunch of stuff in between. Any idea what might cause this? Regards, Chris -- *--Christopher Dumoulin--* Software Team Leader http://ics-ltd.com/ http://ics-ltd.com/ Interactive Circuits and Systems Ltd. 5430 Canotek Road Ottawa, ON K1J 9G2 (613)749-9241 1-800-267-9794 (USA only) This e-mail is private and confidential and is for the addressee only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any hard copies destroyed. You are strictly prohibited from using, printing, distributing or disseminating it or any information contained in it save to the intended recipient.
IMAP_ADDR on PPC 8xx
In our build, (currently based on 2.6.14.3) we define IMAP_ADDR as follows: #define IMAP_ADDR (((bd_t *)__res)-bi_immr_base) With very few exceptions, nearly all driver code that dereferences IMAP_ADDR can be used unchanged and the IMMR value is always the value passed up from the bootloader. We build one image that runs on multiple platforms and some platforms place the IMMR address space at different addresses than others. It's not a constant. Regardless, I see little reason to ioremap() the IMMR address. The MMU is set up in such a way that IMMR based locations can be accessed directly. Ken Poole, MRV Communications, Inc. In a related vein, as I alluded to in my previous email, there has been previous discussion on this list about the fact that it is frowned upon for device drivers to directly dereference IMAP_ADDR. Instead, I've seen a recommendation that each individual driver perform an io_remap() operation on IMAP_ADDR and save the resulting kernel virtual address in a driver-specific data structure. Is this a universally-accepted viewpoint? Is this something that the community agrees should be fixed and we're just waiting for someone (like me) to volunteer to fix all the drivers? Or are there arguments in favor of keeping the direct IMAP_ADDR dereferences? For example, if each driver performs its own separate io_remap(), doesn't that have potentially negative consequences on the VM system for some PPC implementations (e.g. increased contention for TLB entries)? Are these issues addressed by or otherwise impacted by other ongoing PPC Linux work such as the ppc + ppc64 -- powerpc effort / flat device tree stuff??? -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060509/86fca084/attachment.htm
IMAP_ADDR on PPC 8xx
On Tue, 2006-05-09 at 14:38 -0400, Kenneth Poole wrote: In our build, (currently based on 2.6.14.3) we define IMAP_ADDR as follows: #define IMAP_ADDR (((bd_t *)__res)-bi_immr_base) Yes, this is (part of) what our 2.6.11.7-based patch does. With very few exceptions, nearly all driver code that dereferences IMAP_ADDR can be used unchanged and the IMMR value is always the value passed up from the bootloader. We build one image that runs on multiple platforms and some platforms place the IMMR address space at different addresses than others. It?s not a constant. Exactly. I think this kind of automatic adaption to the particular platform is what should be in the vanilla kernel. Regardless, I see little reason to ioremap() the IMMR address. This was the second major part of our 2.6.11.7-based patch. It performed a single ioremap(), stored the result in a global pointer, and then used that pointer in all the drivers instead of using IMAP_ADDR directly. Personally, I don't have a strong opinion yet as to whether this is desirable or not. The MMU is set up in such a way that IMMR based locations can be accessed directly. I'm still rather fuzzy on whether one can count on this always being the case on all PPC variants. () Ken Poole, MRV Communications, Inc. Thanks! Walt
IMAP_ADDR on PPC 8xx
In message 1147194879.2200.41.camel at excalibur.timesys.com you wrote: Thanks again for the advice. Interestingly, I gave the wrong address above. It wasn't 0x2200, it was 0x0220 (i.e. even lower!). And yet with the io_remap()'ed global variable patch, 2.6.11.7 does indeed work on this board with this U-Boot Perhaps this works because this particular board only has 8MiB of RAM It does not work. It will certainly crash as soon as you start a few user space applications. Bottom line: I'm wondering what the Linux PPC community thinks is the correct long term solution to these discrepancies. Should we the community declare Freescale U-Boots are considered harmful; never use them; always use the official U-Boot sources ??? Indeed it would be nice if Freescale worked more directly with the community. Or should we create a kernel mechanism to automatically adapt to the different U-Boot flavors? No, of course not. U-Boot is just one boot loader, there are many others, and the kernel hast to stay independent. And it is definitely not the kernel's fault if the boot loader sets up a braindamaged memory map. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie
IMAP_ADDR on PPC 8xx
On Tue, 2006-05-09 at 22:22 +0200, Wolfgang Denk wrote: In message 1147194879.2200.41.camel at excalibur.timesys.com you wrote: Thanks again for the advice. Interestingly, I gave the wrong address above. It wasn't 0x2200, it was 0x0220 (i.e. even lower!). And yet with the io_remap()'ed global variable patch, 2.6.11.7 does indeed work on this board with this U-Boot Perhaps this works because this particular board only has 8MiB of RAM It does not work. It will certainly crash as soon as you start a few user space applications. Well, something interesting is certainly going on because our 2.6.11.7 kernel *does* work and *does not* crash when running user space applications. It runs BusyBox quite happily with multiple processes (e.g. 3 incoming telnet sessions, a console shell, etc.). I can only conclude that there is something more to our 2.6.11.7-based patch than I currently understand. Cheers! Walt
When is it safe to start using ioremap?
At what point in the linux boot sequence can/should you start using ioremap to get a virtual address to hardware? Early on (in head_4xx.S), I'm setting up a TLB entry to access my hardware, but eventually my TLB entry will be overwritten, and at this point I would like to call ioremap to get an address for accessing my hardware. I'm having trouble figuring out when the original TLB entry will be overwritten (can that even be determined?), and at what point I can start calling ioremap. Any help is appreciated. Cheers, Chris Dumoulin -- *--Christopher Dumoulin--* Software Team Leader http://ics-ltd.com/ http://ics-ltd.com/ Interactive Circuits and Systems Ltd. 5430 Canotek Road Ottawa, ON K1J 9G2 (613)749-9241 1-800-267-9794 (USA only) This e-mail is private and confidential and is for the addressee only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any hard copies destroyed. You are strictly prohibited from using, printing, distributing or disseminating it or any information contained in it save to the intended recipient.
IMAP_ADDR on PPC 8xx
On May 9, 2006, at 3:52 PM, Walter L. Wimer III wrote: Exactly. I think this kind of automatic adaption to the particular platform is what should be in the vanilla kernel. This does not mean you can choose some arbitrary value. There is a small range of high memory addresses that will work successfully for IMMR. You may not see any problems right away, but depending upon drivers selected and the software features used, some problems will crop up. There are also MMU performance enhancements that may be used with certain values, and guaranteed kernel crashes at some point in the future when abused. With Linux, the IMMR should always have a value of 0xf000 or 0xff00 for best results. This was the second major part of our 2.6.11.7-based patch. It performed a single ioremap(), stored the result in a global pointer, and then used that pointer in all the drivers instead of using IMAP_ADDR directly. This is not an acceptable practice. We are removing all global pointers like this, and any driver that needs access to some or all of the IMMR space should be individually mapping those regions it needs. Under the covers of ioremap() we are performing various alignment and reuse of address spaces in order to support things like performance enhancements and cache coherent regions. Thanks. -- Dan
Viable PPC platform?
-Original Message- From: linuxppc-embedded-bounces+marc.howard=kla-tencor.com at ozlabs.or g [mailto:linuxppc-embedded-bounces+marc.howard=kla- tencor.com at ozlabs.org] On Behalf Of Wolfgang Denk Sent: Tuesday, May 09, 2006 3:31 PM To: Eugene Surovegin Cc: linuxppc-embedded at ozlabs.org Subject: Re: Viable PPC platform? In message 20060509171520.GA10886 at gate.ebshome.net you wrote: After many years of doing embedded Linux stuff I still don't understand why people are so fond of initrd. For temporary stuff - tempfs is much better and flexible. For r/o stuff - just make separate MTD partition (cramfs, squashfs) and mount it directly as root. Both options will waste significantly less memory. Agreed. And if somebody wants to see facts and numbers, please see http://www.denx.de/wiki/view/DULG/RootFileSystemSelection One size does not fit all. We have an application with a very large file system. It can't fit in the available flash, however we do have a ton of RAM (512MB). NFS is not an option nor is it desirable (latency and availability issues). Boot time is not an issue either in this case as it takes the equipment many minutes to calibrate and initialize. initrd also solves another problem. The combined uBoot multi-image although huge (32 MB) represents a complete system firmware snapshot in a single (huge) file. By selecting the appropriate uImage the host can guarantee the linux build, device drivers, application version and FPGA firmware revs (the embedded board is rebooted to guarantee a repeatable starting state). This makes revision control for the overall system much easier, especially since the host system is running windoze. I agree with your general conclusion but there are specific cases where it is not optimal. Marc W. Howard
Viable PPC platform?
On Tue, May 09, 2006 at 03:52:20PM -0700, Howard, Marc wrote: In message 20060509171520.GA10886 at gate.ebshome.net you wrote: After many years of doing embedded Linux stuff I still don't understand why people are so fond of initrd. For temporary stuff - tempfs is much better and flexible. For r/o stuff - just make separate MTD partition (cramfs, squashfs) and mount it directly as root. Both options will waste significantly less memory. Agreed. And if somebody wants to see facts and numbers, please see http://www.denx.de/wiki/view/DULG/RootFileSystemSelection One size does not fit all. We have an application with a very large file system. It can't fit in the available flash, however we do have a ton of RAM (512MB). NFS is not an option nor is it desirable (latency and availability issues). Boot time is not an issue either in this case as it takes the equipment many minutes to calibrate and initialize. initrd also solves another problem. The combined uBoot multi-image although huge (32 MB) represents a complete system firmware snapshot in a single (huge) file. By selecting the appropriate uImage the host can guarantee the linux build, device drivers, application version and FPGA firmware revs (the embedded board is rebooted to guarantee a repeatable starting state). This makes revision control for the overall system much easier, especially since the host system is running windoze. This all is nice provided you use network for boot. IMHO this is quite _rare_ setup (especially Windows host!!!). For 99% of embedded designs this is obviously not a viable option. -- Eugene
Viable PPC platform?
-Original Message- From: Eugene Surovegin [mailto:ebs at ebshome.net] In message 20060509171520.GA10886 at gate.ebshome.net you wrote: After many years of doing embedded Linux stuff I still don't understand why people are so fond of initrd. One size does not fit all. We have an application with a very large file system. It can't fit in the available flash, however we do have a ton of RAM (512MB). NFS is not an option nor is it desirable (latency and availability issues). Boot time is not an issue either in this case as it takes the equipment many minutes to calibrate and initialize. initrd also solves another problem. The combined uBoot multi-image although huge (32 MB) represents a complete system firmware snapshot in a single (huge) file. By selecting the appropriate uImage the host can guarantee the linux build, device drivers, application version and FPGA firmware revs (the embedded board is rebooted to guarantee a repeatable starting state). This makes revision control for the overall system much easier, especially since the host system is running windoze. This all is nice provided you use network for boot. IMHO this is quite _rare_ setup (especially Windows host!!!). For 99% of embedded designs this is obviously not a viable option. -- Eugene Again, I agree. I just wanted to show you at least one case where initrd is the best solution, IMHO. As for a linux board booting off of a windoze host I prefer to think of it as an island of sanity in a sea of chaos. Marc W. Howard
