consistent_free()
David Gibson wrote: (2) seems very strange. It doesn't seem in keeping with the meaning of PageReserved (well my best guess at the meaning from only slightly illuminating comments in page.h). It looks strange to me as well, and wouldn't do that part. I called map_page() directly to avoid doing this, and in return we can just call vfree() to get rid of the space. Which makes me wonder how the hell anything works now, since remap_page_range() is apparently called from several places. I could only find a few places where it is called, and it seems to always be called on pages that have been previously reserved (kernel ram or I/O space). One of the advantages of making the page reserved in this case is you can then mmap() it from a user application and get DMA to/from user space to work. Normally, an mmap() from user space on memory gets you new, zeroed pages. My only concern about not marking the pages reserved is ensuring they are not eligible for swapping. That would kind of suck if it happened :-) -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
consistent_free()
On Wed, Jun 26, 2002 at 01:33:55AM -0400, Dan Malek wrote: David Gibson wrote: (2) seems very strange. It doesn't seem in keeping with the meaning of PageReserved (well my best guess at the meaning from only slightly illuminating comments in page.h). It looks strange to me as well, and wouldn't do that part. I called map_page() directly to avoid doing this, and in return we can just call vfree() to get rid of the space. Well that's the doubly odd thing. After marking the pages reserved the ARM consistent_alloc() then uses its own functions, not remap_page_range() to do the remapping. From the looks of it they have the same structure as the remap_page_range(), but are without the (broken?) test and I think have little effective difference to our direct calling of map_page(). So the setting of PG_reserved will only affect attempts to remap_page_range() on the physical pages after they have already been consistent_alloc()ed. I can't see why you'd want to do that. Which makes me wonder how the hell anything works now, since remap_page_range() is apparently called from several places. I could only find a few places where it is called, and it seems to always be called on pages that have been previously reserved (kernel ram or I/O space). Hmm.. ok. That does seem a bit odd - the comment above remap_page_range() says that it will create null mappings if the page doesn't exist. But it seems from the code that it will create null mappings if the page *does* exist and will only create real mappings if the page doesn't exist or is reserved. AFAICT most kernel ram is not PageReserved, only leftover bootmem. IO memory won't usually be reserved - in general it won't even have a struct page at all. One of the advantages of making the page reserved in this case is you can then mmap() it from a user application and get DMA to/from user space to work. Normally, an mmap() from user space on memory gets you new, zeroed pages. I don't see how PG_reserved helps this particularly. As long as the driver implementing the mmap() allocates the physical memory (so the VM won't take it away from us) before mapping it into user space. It's probably also a good idea for the driver to maintain its own virtual (uncached) mapping as well as the userspace one. So using consistent_alloc() and then remapping the physical addresses into userspace should suffice. My only concern about not marking the pages reserved is ensuring they are not eligible for swapping. That would kind of suck if it happened :-) It certainly would. I don't think pages that we've allocated with get_free_pages() will be swapped (just like kmalloc()ed pages won't be), but I don't know enough about the VM to be sure. -- David Gibson| For every complex problem there is a david at gibson.dropbear.id.au | solution which is simple, neat and | wrong. -- H.L. Mencken http://www.ozlabs.org/people/dgibson ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
SELF and JFFS2????
Hi there, has anyone successfully used DENX SELF to create an root fs _and_ put it then on a JFFS2 partion? I would like to create a flash disk just as easy as you can create a ramdisk with SELF. But for now the problem is that mkfs.jffs2 does _not_ handle (busybox) hardlinks correctly - well at least not the way I want. Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
SELF and JFFS2????
Maybe you could change the Makefile so that it creates symbolic links to /bin/busybox instead of hardlinks. The only drawback to this is that you end up using one inode per link, instead of one inode for all the links. As long as you've got the space to waste this won't be a problem. Alex Steven Scholz wrote: Hi there, has anyone successfully used DENX SELF to create an root fs _and_ put it then on a JFFS2 partion? I would like to create a flash disk just as easy as you can create a ramdisk with SELF. But for now the problem is that mkfs.jffs2 does _not_ handle (busybox) hardlinks correctly - well at least not the way I want. Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cramfs for root filesystem?
Stephen Cameron wrote: I have tried to fix up the endian-swapping patch for the mkcramfs from sourceforge CVS, circa Mon Jun 24, 2002 :pserver:anonymous at cvs.cramfs.sourceforge.net:/cvsroot/cramfs If you are going to take that version of mkcramfs, you could just as well take the corresponding version of the cramfs fs implemention since it hardwires conversion to *little endian* into the kernel Yes, this would be the preferable solution, and is what I looked for first, but I didn't know it was done already. Where can I get that? Oh! Duh! Now I see it! (knocking self on head :-) I hadn't noticed that I got it up when I did the cvs co . to check out mkcramfs from sourceforge. I wasn't expecting kernel parts in there. I just tried it out, and it works great! Thanks for saving me some effort. -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
SELF and JFFS2????
Steven, has anyone successfully used DENX SELF to create an root fs _and_ put it then on a JFFS2 partion? FWIW, the Elinos DevKit contains an example project to do just that. It allows to format the MTD device, and download and install another project onto it. Regards, Marius - Marius Groeger SYSGO Real-Time Solutions GmbH mgroeger at sysgo.de Software Engineering Embedded and Real-Time Softwarewww.sysgo.de Voice: +49-6136-9948-0 Am Pfaffenstein 14 www.osek.de FAX: +49-6136-9948-10 55270 Klein-Winternheim, Germany www.elinos.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
SELF and JFFS2????
Marius Groeger wrote: FWIW, the Elinos DevKit contains an example project ... Is the Elinos DevKit as free as Linux kernel (or for example ELDK) ? Ludwig ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
contiguous kernel pages
Hello, We are observing some undesirable behavior in the way the PowerPC kernel handles page allocation. We wrote a simple program that mallocs a 2MB buffer and does various read and write operations. After booting Linux we see numbers like: Write sequential: 673.550324 MB/S Read sequential: 470.949462 MB/S Write sequential: 499.278523 MB/S Read sequential: 310.924958 MB/S Write cache lines: 84.746262 MB/S Read cache lines: 147.659226 MB/S Write 2 cache lines: 87.324496 MB/S Read 2 cache lines: 153.067388 MB/S Write 37 words: 84.047736 MB/S Read 37 words: 123.959971 MB/S Random writes: 44.707562 MB/S Random reads: 31.423328 MB/S After running for a while (doing compiles and miscellaneous stuff), the performance deteriorates and stays that way. When we run our program after a lot of system activity we see numbers like: Write sequential: 305.289433 MB/S Read sequential: 214.440869 MB/S Write sequential: 369.741795 MB/S Read sequential: 162.424933 MB/S Write cache lines: 28.616503 MB/S Read cache lines: 46.471531 MB/S Write 2 cache lines: 23.170304 MB/S Read 2 cache lines: 47.261479 MB/S Write 37 words: 32.125045 MB/S Read 37 words: 51.199579 MB/S Random writes: 45.648529 MB/S Random reads: 18.494342 MB/S As you can see, some operations are less than 1/2 speed. We suspected that this was due to page fragmentation. We wrote a special driver to malloc contiguous kernel pages. When we use it the numbers do not deteriorate. We suspect that the kernel has been optimized for a much smaller cache. Where should we be looking to make the kernel allocate larger contiguous chunks of memory? Because the PowerPc L2 is 2 way and 2MB in size, we suspect that we need to tell the kernel to attempt to allocate 1MB chunks of memory whenever possible. Any thoughts? This behavior is the same on all PowerPC machines we have (Synergy, Mac's, others). Thanks, - Dave -- Dave Wilhardt Synergy Microsystems ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
AMD Flash Interface for updating boot flash
Just define your flash as a MTD device and then, from user space use dd command to copy your bootloader to flash: dd if=bootloader of=/dev/mtdblock0 Best Regards, Michael Meriin - Original Message - From: Chuck Partridge [EMAIL PROTECTED] To: linuxppc-embedded at lists.linuxppc.org Sent: Wednesday, June 26, 2002 17:09 Subject: AMD Flash Interface for updating boot flash Hello all, I have been searching the archives and I am a bit confused, so bear with me if this is too simple a question. I need to provide a way to update my boot flash from user space. Our user application will download an boot flash image and save it (to a file or a buffer), we must then write the flash. I have seen references in the archives to Denx's drivers/char/amd_flash.c and to MTD drivers, or I can implement my own driver, but I'm not sure of the best (i.e. easiest and cleanest) way. I don't need to put a file system on the flash. All it does is hold the PPCBoot image. The flash part is an AMD 29LV004B and is setup for 8 bit interface. I am running a 2.4.17 kernel on an 8245. Any suggestions? Thanks, Chuck ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
contiguous kernel pages
Dave Wilhardt wrote: As you can see, some operations are less than 1/2 speed. We suspected that this was due to page fragmentation. What do you mean by page fragmentation and how to see this causing the performance difference you see? I suspect I know the answer, I just want to know what you are thinking :-) We suspect that the kernel has been optimized for a much smaller cache. Where should we be looking to make the kernel allocate larger contiguous chunks of memory? The kernel doesn't know anything about processor caches and simply allocates a 4K page at a time when they are faulted for the first time. Your malloc() doesn't allocate any real memory when it is called, just the virtual space to map it. When you touch the pages for the first time, they are zeroed and mapped. What did your special driver do to allocate pages and map them into an application? . Because the PowerPc L2 is 2 way and 2MB in size, we suspect that we need to tell the kernel to attempt to allocate 1MB chunks of memory whenever possible. Any thoughts? Yes, but allocating 1M chunks of memory isn't the answer. We need to implement a cache coloring algorithm, but I'm surprised you can so easily cause your performance problem, as I would think we would have to write a specific allocation algorithm for force the behavior you see :-) It would be interesting to see your test as well, since that is quite a variation in performance within a single test session. Thanks. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
AMD Flash Interface for updating boot flash
I agree that MTD is the way to go, but with one small change to Michael's instructions. configure MTD for char driver support, and do dd if=bootloader of=/dev/mtd0 /dev/mtd0 is a raw char device that is best to write a binary boot image to flash, /dev/mtdblock0 is a block device that is best for file system images, which can then be mounted. You can get expert advice from the MTD list: http://lists.infradead.org/mailman/listinfo/linux-mtd/ Jan Michael Meriin Michael at KSWaves.com Sent by: owner-linuxppc-embedded at lists.linuxppc.org 06/26/2002 12:17 PM To: Chuck Partridge Chuck_Partridge at amx.com, linuxppc-embedded at lists.linuxppc.org cc: Subject:Re: AMD Flash Interface for updating boot flash Just define your flash as a MTD device and then, from user space use dd command to copy your bootloader to flash: dd if=bootloader of=/dev/mtdblock0 Best Regards, Michael Meriin - Original Message - From: Chuck Partridge [EMAIL PROTECTED] To: linuxppc-embedded at lists.linuxppc.org Sent: Wednesday, June 26, 2002 17:09 Subject: AMD Flash Interface for updating boot flash Hello all, I have been searching the archives and I am a bit confused, so bear with me if this is too simple a question. I need to provide a way to update my boot flash from user space. Our user application will download an boot flash image and save it (to a file or a buffer), we must then write the flash. I have seen references in the archives to Denx's drivers/char/amd_flash.c and to MTD drivers, or I can implement my own driver, but I'm not sure of the best (i.e. easiest and cleanest) way. I don't need to put a file system on the flash. All it does is hold the PPCBoot image. The flash part is an AMD 29LV004B and is setup for 8 bit interface. I am running a 2.4.17 kernel on an 8245. Any suggestions? Thanks, Chuck ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
AMD Flash Interface for updating boot flash
Where do you set this up? If I want to use partitions, where do I put the info on how it is partitioned? I modified the kernel .config and it gives me the following startup messages: physmap flash device: 8 at fff0 CFI: Found no Physically mapped flash device at location zero I'll check out the MTD list. Chuck Jan.Rovins at radisys.com 06/26/02 02:49PM I agree that MTD is the way to go, but with one small change to Michael's instructions. configure MTD for char driver support, and do dd if=bootloader of=/dev/mtd0 /dev/mtd0 is a raw char device that is best to write a binary boot image to flash, /dev/mtdblock0 is a block device that is best for file system images, which can then be mounted. You can get expert advice from the MTD list: http://lists.infradead.org/mailman/listinfo/linux-mtd/ Jan Michael Meriin Michael at KSWaves.com Sent by: owner-linuxppc-embedded at lists.linuxppc.org 06/26/2002 12:17 PM To: Chuck Partridge Chuck_Partridge at amx.com, linuxppc-embedded at lists.linuxppc.org cc: Subject:Re: AMD Flash Interface for updating boot flash Just define your flash as a MTD device and then, from user space use dd command to copy your bootloader to flash: dd if=bootloader of=/dev/mtdblock0 Best Regards, Michael Meriin - Original Message - From: Chuck Partridge [EMAIL PROTECTED] To: linuxppc-embedded at lists.linuxppc.org Sent: Wednesday, June 26, 2002 17:09 Subject: AMD Flash Interface for updating boot flash Hello all, I have been searching the archives and I am a bit confused, so bear with me if this is too simple a question. I need to provide a way to update my boot flash from user space. Our user application will download an boot flash image and save it (to a file or a buffer), we must then write the flash. I have seen references in the archives to Denx's drivers/char/amd_flash.c and to MTD drivers, or I can implement my own driver, but I'm not sure of the best (i.e. easiest and cleanest) way. I don't need to put a file system on the flash. All it does is hold the PPCBoot image. The flash part is an AMD 29LV004B and is setup for 8 bit interface. I am running a 2.4.17 kernel on an 8245. Any suggestions? Thanks, Chuck ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
AMD Flash Interface for updating boot flash
Chuck, The newer MTD versions may have more/different config options than the documented examples floating around. but here is some tips off the top of my head: You should set : CONFIG_MTD_CFI CONFIG_MTD_AMDSTD and choose the geometry support for the buswidth/interleave of your flash bank. set CONFIG_MTD_CHAR for raw access, CONFIF_MTD_BLOCK if you want to mount a flash file system and specify a Mapping. Basically, if your board is from a well known vendor, there may be a Mapping Driver already written for it, so you should go with that. if you have a custom board, you may be able to go without a mapping driver if you specify the correct physical mapping CONFIG_MTD_PHYSMAP and fill in the details of your hardware If you just need to store a single image, you wont need partitions, if you want a boot image and a flash file system, or backup copies of the previous boot image, then partitions are the way to go. If you need to have partitions, you will have to write your own mapping driver, because the partition sizes are specified there, just pick a pre-existing mapping driver that is close to your board/flash then cut paste hack away. (There may be newer versions of MTD that let you specify partitions from the .config file, I am not sure of this) After you try the above, and MTD still cant find your flash, the folks on the MTD list can take it from there. one last warning: certain versions of the 2.4 kernel have non stable versions of mtd, you may be guided to download a stable snapshot from their website. Jan Chuck Partridge Chuck_Partridge at amx.com Sent by: owner-linuxppc-embedded at lists.linuxppc.org 06/26/2002 04:23 PM To: Michael at KSWaves.com, Jan.Rovins at radisys.com cc: linuxppc-embedded at lists.linuxppc.org Subject:Re: AMD Flash Interface for updating boot flash Where do you set this up? If I want to use partitions, where do I put the info on how it is partitioned? I modified the kernel .config and it gives me the following startup messages: physmap flash device: 8 at fff0 CFI: Found no Physically mapped flash device at location zero I'll check out the MTD list. Chuck Jan.Rovins at radisys.com 06/26/02 02:49PM I agree that MTD is the way to go, but with one small change to Michael's instructions. configure MTD for char driver support, and do dd if=bootloader of=/dev/mtd0 /dev/mtd0 is a raw char device that is best to write a binary boot image to flash, /dev/mtdblock0 is a block device that is best for file system images, which can then be mounted. You can get expert advice from the MTD list: http://lists.infradead.org/mailman/listinfo/linux-mtd/ Jan Michael Meriin Michael at KSWaves.com Sent by: owner-linuxppc-embedded at lists.linuxppc.org 06/26/2002 12:17 PM To: Chuck Partridge Chuck_Partridge at amx.com, linuxppc-embedded at lists.linuxppc.org cc: Subject:Re: AMD Flash Interface for updating boot flash Just define your flash as a MTD device and then, from user space use dd command to copy your bootloader to flash: dd if=bootloader of=/dev/mtdblock0 Best Regards, Michael Meriin - Original Message - From: Chuck Partridge [EMAIL PROTECTED] To: linuxppc-embedded at lists.linuxppc.org Sent: Wednesday, June 26, 2002 17:09 Subject: AMD Flash Interface for updating boot flash Hello all, I have been searching the archives and I am a bit confused, so bear with me if this is too simple a question. I need to provide a way to update my boot flash from user space. Our user application will download an boot flash image and save it (to a file or a buffer), we must then write the flash. I have seen references in the archives to Denx's drivers/char/amd_flash.c and to MTD drivers, or I can implement my own driver, but I'm not sure of the best (i.e. easiest and cleanest) way. I don't need to put a file system on the flash. All it does is hold the PPCBoot image. The flash part is an AMD 29LV004B and is setup for 8 bit interface. I am running a 2.4.17 kernel on an 8245. Any suggestions? Thanks, Chuck ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
