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 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 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.
Help Needed: input overrun(s)
Hi all, I am currently involve in development of Multi-Channel Controller (MCC) driver for MPC8260 processor. Whenever we are loading the driver, on the console we are receiving a print ttyS: 1 input overrun(s) along with other prints of the driver and resulting in scrambled output. Can anyone suggest why this is happening? Is the driver affecting the uart driver? We have seen the memory map thoroughly, there is no issue of memory conflict. Any help in this regards, I will be grateful. Thnaks and regards, Souvik Maiti Tata Consultancy Services Limited Mailto: s.maiti at tcs.com Website: http://www.tcs.com =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
Kernel panic - not syncing: No init found.
I try to make a new uRamdisk for my bubinga board(linux-2.6.14,PPC405EP). actully I just copy the most of the files in the board,and compiled busybox with ppc tools. but when I use the new uRamdisk for a try,it just showed up this errors(as follow),then reboot,back and forth... ** RAMDISK: incomplete write (-28 != 32768) 4194304 EXT2-fs warning: checktime reached, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 116k init attempt to access beyond end of device //this is where the error begins. ram0: rw=0, want=10330, limit=8192 Buffer I/O error on device ram0, logical block 5164 attempt to access beyond end of device ram0: rw=0, want=10330, limit=8192 Buffer I/O error on device ram0, logical block 5164 attempt to access beyond end of device ram0: rw=0, want=10330, limit=8192 Buffer I/O error on device ram0, logical block 5164 attempt to access beyond end of device ram0: rw=0, want=10330, limit=8192 Buffer I/O error on device ram0, logical block 5164 Kernel panic - not syncing: No init found. Try passing init= option to kernel. //according to this note,is there something I have to do with my kernel?? 0Rebooting in 1 seconds.. * Any help is appreciated. regards tony
Calculating virtual address from physical address
Chris Dumoulin wrote: Thanks for your reply; I found it very useful and interesting. Now, I have a whole bunch of questions. You said that the temporary TLB entries setup in head_4xx.S will eventually be replaced. Where is the code that creates these new TLB entries later on? Are the 'real' TLB entries only created once, and persist for as long as the system is running, or do TLB entries change often while the system is running? It has been a few months since I was deep in this, so I am weaker on details at the moment. But the gist is that the MMU in PowerPC's is primarily software driven. It functions as a cache - there are alot of details, but unless you arfe getting really deep into memory management you can think of the MMU as a 64 entry cache. Software - in this instance the Linux VM system is responsible for deciding exactly what happens when the cache is full and a new entry needs added. Manually stuffing an entry into the MMU is safe up until that event occurs. The VM system entries (real entries if you wish) are in Linux Memory management data structures - page tables etc. When a page fault occurs Linux looks up the correct entry in its tables and replaces one in the MMU with the required one. Unlike X86's where much of this is implimented in hardware, in a PowerPC the replacement algorithm can be anything you want - it is written in software. Therefore handling page faults is likely to be slower, but the OS is in total control of all aspects of Memory management. It has very few constraints imposed on it by the MMU. Real entries are created and destroyed inside the kernel by anything that wants memory. Drivers demand mapping of IO based memory typically when they initiallize and should release it when they unload. Programs request memory when they need it and release it when they are done. There are subtle differences between IO memory mapping - the virtual address for an IO mapped memory device MUST corresponf to a specific set of addresses, while ordinary requests for a memory mapping can be satisfied by most any block of memory. Do you know what state the MSR will be in at this point in the code? I know what the power-on reset state is, but I'm wondering if it'll be in a different state by the time we get to this point in head_4xx.S. I am not sure that Linux sets the MSR at any point prior to head_4xx.S. Regardless, greping the ppc directories within kernel source for MSR_KERNEL will expose the bits their definitions and the normal state, In my instance to avoid machine checks I had to conditionally redefine MSR_KERNEL in one header file to avoid machine checks. When you suggest disabling instruction or data address translation, is that just so I could access my hardware directly, or is there some other reason? Atleast for me getting through the rfi to start_here: which should be where you end up immediately after the rfi proved very difficult. by enabling bits one at a time I was able to test what was happening and establish what was working. I.E if you only enable instruction translation, you can still write to your physical IO port, but the 'rfi' will take you to the virtual address 'start_here:' This was solely a debugging and problem isolation approach. It also enabled me to test things bit by bit and assure my self that everything worked, while loading the MSR with the default KERNEL MSR value and executing the rfi presumes that a number of things are all setup properly - a failure in any of them would create a problem. It is not often in programming that a single instructions makes so many changes all at once, and therefore in one instant requires so many of them to be right. I actually wrote some code the stuffed a value at specific physical addresses, turned on data address mapping, read the value from the correct virtual address turned of mapping and then wrote the value to my debug port. I also was able to test the TLB entry I inserted the same way. The bit by bit approach is just a way to figure out why you can not get from real mode to virtual mode by dividing the problem into small testable peices. You were enabling the MSR bits, one at a time, and found that the machine check was causing the hang (I'm assuming that's what you meant by 'sent me to space'). Was the idea there to just isolate what type of exception was causing the hang, or were you looking to make some permanent changes to the MSR? Is a machine check interrupt caused by trying to access an address that doesn't have a TLB entry? Unless I am completely mistaken, machine checks are not cause by softwded are or programming errors, they are cause by hardware problems, or atleast by hardware reporting problems In my instance I forwarded I c the problem to the FPGA programmers, and disabled the machine check so that I could move on. I was able to get some clues prior to my bit by bit tests.
Viable PPC platform?
On Tue, 9 May 2006 10:15:20 -0700 Eugene Surovegin ebs at ebshome.net wrote: 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. Okay, let me qualify my answer. It depends on whether you need to make persistent changes to the filesystem in flash. If so, and given that your flash is only 4MB, I would recommend moving files to somewhere else, e.g. an initrd, because if when a JFFS2 FS is approaching full, you often find that writes to flash hang while JFFS2 searches for blocks to use as a scratchpad. This has been my experience anyway. If you don't need to make persistent changes to files, then I'm sure cramfs in flash as a rootfs would work well, with a tmpfs partition mounted on /tmp and /var. Alex
Help Needed: input overrun(s)
Hello, On Wed, 2006-05-10 at 06:33, s.maiti at tcs.com wrote: Hi all, I am currently involve in development of Multi-Channel Controller (MCC) driver for MPC8260 processor. Whenever we are loading the driver, on the console we are receiving a print ttyS: 1 input overrun(s) along with other prints of the driver and resulting in scrambled output. Can anyone suggest why this is happening? Is the driver affecting the uart driver? As far as UART driver is concerned, it could be affected if you did not carefully allocate some resources. Are you using MCC1 or MCC2? Channel specific parameters of MCC1 (channels 0-127) are at the beginning of the DPRAM (channel CH_NUM at address 64*CH_NUM). UART driver (as well as ethernet driver) allocates its buffer descriptors with m8260_cpm_dpalloc. I think that allocating with this function starts at the beginning of the DPRAM, so you might have overwritten UART's buffer descriptors. So, use MCC2 if you can. If you use some BRGs in your MCC driver you should check that as well. We have seen the memory map thoroughly, there is no issue of memory conflict. Any help in this regards, I will be grateful. Thnaks and regards, Souvik Maiti Tata Consultancy Services Limited Mailto: s.maiti at tcs.com Website: http://www.tcs.com =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded Regards, Stevan
Kernel panic - not syncing: No init found.
On 5/10/06, hangtoo hangtoo at 163.com wrote: I try to make a new uRamdisk for my bubinga board(linux-2.6.14,PPC405EP). actully I just copy the most of the files in the board,and compiled busybox with ppc tools. but when I use the new uRamdisk for a try,it just showed up this errors(as follow),then reboot,back and forth... ** RAMDISK: incomplete write (-28 != 32768) 4194304 I'm pretty sure this tells me that your ramdisk is not big enough. Take a look at http://www.vanemery.com/Linux/Ramdisk/ramdisk.html If you are using LILO like in the example listed at the link above, you need to make sure your ramdisk_size parameter is big enough. That's what my gues is. -stv
Help Needed: input overrun(s)
-Original Message- From: Stevan Ignjatovic Hello, console we are receiving a print ttyS: 1 input overrun(s) along with other prints of the driver and resulting in scrambled output. Can anyone suggest why this is happening? Is the driver affecting the uart driver? As far as UART driver is concerned, it could be affected if you did not carefully allocate some resources. Are you using MCC1 or MCC2? Channel specific parameters of MCC1 (channels 0-127) are at the beginning of the DPRAM (channel CH_NUM at address 64*CH_NUM). UART driver (as well as ethernet driver) allocates its buffer descriptors with m8260_cpm_dpalloc. I think that allocating with this function starts at the beginning of the DPRAM, so you might have overwritten UART's buffer descriptors. So, use MCC2 if you can. If you use some BRGs in your MCC driver you should check that as well. We have a MCC driver that we see the same happening on. It only occurs under heavy load (top sows us usig 20-40 % cpu in interrupt). I am pretty confident that we are not overwriting uart DPRAM. (MCC1 only uses the middle 64 channels, skipping over the first 32 where the conflict witht he UARTS are) I have not seen it corrupt anything, so we have more or less ignored it. Our theory is that it happens when the CPM gets overloaded. It would be nice to actually fix it though
IMAP_ADDR on PPC 8xx
Thanks, Dan! This is exactly the kind of feedback I was seeking. Based on your comments and Wolfgang's comments, I conclude that: 1. The U-Boots on my MPC885ADS and MPC8272ADS boards are unequivocally broken and should be replaced with ones from the official U-Boot source repositories that use IMMR values matching the Linux kernel source. 2. For now, there is no pressing need to fix the existing drivers; they may continue dereferencing IMAP_ADDR directly as they currently do. 3. In the future, the drivers will ultimately migrate toward individually calling ioremap() and maintaining their own private pointers. Thanks again, Walt On Tue, 2006-05-09 at 17:51 -0400, Dan Malek wrote: 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
Calculating virtual address from physical address
On Wed, May 10, 2006 at 07:04:30AM -0400, David H. Lynch Jr. wrote: [skip] Unless I am completely mistaken, machine checks are not cause by softwded are or programming errors, they are cause by hardware problems, You can trivially trigger MachineChecks without any hardware problems - just map some non-existent physical address and try to access it. -- Eugene
Viable PPC platform?
On Wed, May 10, 2006 at 12:11:41PM +0100, Alex Zeffertt wrote: On Tue, 9 May 2006 10:15:20 -0700 Eugene Surovegin ebs at ebshome.net wrote: 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. Okay, let me qualify my answer. It depends on whether you need to make persistent changes to the filesystem in flash. If so, and given that your flash is only 4MB, I would recommend moving files to somewhere else, e.g. an initrd, because if when a JFFS2 FS is approaching full, you often find that writes to flash hang while JFFS2 searches for blocks to use as a scratchpad. This has been my experience anyway. If you don't need to make persistent changes to files, then I'm sure cramfs in flash as a rootfs would work well, with a tmpfs partition mounted on /tmp and /var. You missed my point. initrd should be stored somewhere - in the same flash . In this case there is no reason to actually use initrd instead of just direct mount from flash. -- Eugene
IMAP_ADDR on PPC 8xx
On May 10, 2006, at 12:49 PM, Walter L. Wimer III wrote: FYI, here's a table from the MPC885ADS PowerQUICC(tm) Application Development System User's Guide, available on Freescale's website. This table seems to confirm how they've configured their U-Boot -- the IMMR is set to 0x0220... Freescale never ported U-Boot to the MPC855ADS platform, and I don't believe it came with any software at all. This IMMR value was chosen to be backward compatible with some old software tools to get a compact address space without the need of using the MMU, long before we had Linux running on the platform. This may be fine for non-Linux purposes, but it looks like we need to spread some gospel to Freescale regarding the correct IMMR address for U-Boot / Linux I think you better be pointing fingers at the clueless person that provided the software you have, as it didn't come from Freescale nor any of the public U-Boot sources. Thanks. -- Dan
Need help debugging
ok, so I've got my BDI2000 working and talking to my 8260. I read as much info as I could find on this but I still think I'm missing something. I have a uBoot image and I wait for the system to download my kernel. Not through the BDI, I just let the uBoot boot image do it the normal way. I start it by telling the BDI to go. Then what I want to do is connect to my linux kernel after the kernel is up and running so I do: (gdb) target remote bdi:2001 Remote debugging using bdi:2001 0xc000c9cc in ??() (gdb) Then I add my symbol table. (gdb) add-symbol-file vmlinux 0xc000 at that point I get a reset. I turn off the software watchdog in the BDI config file. Is there something I am missing? Thanks in advance. -stv
Help: Linux porting to custom target hw
Hello: Can someone point me in the right direction for some good documentation on the above topic. Following is what I so far have done and what I need to do. 1. Set up host environment based on Fedora Core 4 2. Downloaded 'ppc4xx' tool chain, ELDK and kernel 3. Built U-Boot and uImage 4. Flashed U-Boot on the 2nd flash on the Ocotea board (AMCC440GX PowerPC) 5. Changed the environment variable for NFS mounted root fs and other MAC and IP addresses as needed 6. TFTP uImage at 40 7. bootm and kernel boots all right with root fs mounted on the host I am expecting my hardware based on 440GX end of the month. I told the HW engineer to follow the peripheral i/f as much possible close to the ref. design. We are putting 32MB of Flash and 256MB of RAM. I need some guidance so that I can port U-Boot and the kernel (minimal changes) so that I can bring up the board initially with root fs NFS minted and later on the RAMDISK. Appreciate the help. Regards. -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060510/0fb3653c/attachment.htm
IMAP_ADDR on PPC 8xx
Thanks Dan for the extra info. Just to let everyone know even though this turned out to not be our problem we here at Freescale are looking at how we can make sure this does not happen in the future. We want any uboot shipped with future Freescale boards to have the correct behavior. We also understand the board documentation needs to be changed to mention the appropriate value for IMMR for linux. John jrigby at freescale.com On 5/10/06, Dan Malek dan at embeddedalley.com wrote: On May 10, 2006, at 12:49 PM, Walter L. Wimer III wrote: FYI, here's a table from the MPC885ADS PowerQUICC(tm) Application Development System User's Guide, available on Freescale's website. This table seems to confirm how they've configured their U-Boot -- the IMMR is set to 0x0220... Freescale never ported U-Boot to the MPC855ADS platform, and I don't believe it came with any software at all. This IMMR value was chosen to be backward compatible with some old software tools to get a compact address space without the need of using the MMU, long before we had Linux running on the platform. This may be fine for non-Linux purposes, but it looks like we need to spread some gospel to Freescale regarding the correct IMMR address for U-Boot / Linux I think you better be pointing fingers at the clueless person that provided the software you have, as it didn't come from Freescale nor any of the public U-Boot sources. Thanks. -- Dan ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
IMAP_ADDR on PPC 8xx
On Wed, 2006-05-10 at 13:45 -0400, Dan Malek wrote: This may be fine for non-Linux purposes, but it looks like we need to spread some gospel to Freescale regarding the correct IMMR address for U-Boot / Linux I think you better be pointing fingers at the clueless person that provided the software you have, as it didn't come from Freescale nor any of the public U-Boot sources. My sincerest apologies to Freescale. Upon further research, it appears that it was another TimeSys engineer (who has since moved on to another job) who built and installed U-Boot on our MPC885ADS board. Strangely, it appears that he started with the community U-Boot 1.1.3 and then added a patch to change the IMMR value (plus a few other things). I'm not sure why. He's a very bright guy, so I'm very puzzled Anyway, mystery solved. Again, my sincerest apologies to Freescale. I built the community U-Boot 1.1.4 and flashed it onto our board. Linux 2.6.16.11 now boots much farther than before (I'm now getting printk() output). The kernel is hitting a new problem now, but I suspect it may be related to the TLB code that Marcello has discussed recently. I'm going to go look at that patch next. :-) Thanks. -- Dan Thanks again to everyone!!! Walt Wimer TimeSys Corporation
