Re: [PATCH 06/14] Pramfs: Include files
Sam Ravnborg wrote: It should be possible to read a file-system on your x86 64bit box that you wrote with your small powerpc target. For a (NV)RAM-based filesystem?? WTH??? dd the full image - dig into it. Usefull is you have post-mortem info there. Sam dd? You haven't got any device file to have a dump. I think we're going a bit out of scope. I had some doubt to support rootfs in pram and after some feedback and the comments of this review I think I'll remove it from the next release (to understand some aspects of this fs with the kernel community was my main goal for this review). I agree to use the native endian. As I said the important thing is that if an user want to use it in a 64bit environment then the fs must work well and then it must be designed to support even this situation, I think it's obvious. Marco -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
Pavel Machek wrote: On Mon 2009-06-22 14:50:01, Tim Bird wrote: Pavel Machek wrote: block of fast non-volatile RAM that need to access data on it using a standard filesytem interface. Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are better with ext2. Not if you want the RAM-based filesystem to persist over a kernel invocation. Yes, you'll need to code Persistent, RAM-based _block_device_. Pavel First of all I have to say that I'd like to update the site and make it clearer but at the moment it's not possible because I'm not the admin and I've already asked to the sourceforge support to have this possibility. About the comments: sincerely I don't understand the comments. We have *already* a fs that takes care to remap a piace of ram (ram, sram, nvram, etc.), takes care of caching problems, takes care of write protection, takes care to be persistent, can use xip and it's my intention to add in the next future other features like acl, xattr and so on. You are talked about journaling. This schema works well for a disk, but what about a piece of ram? What about a crazy kernel that write in that area for a bug? Do you remember for example the e1000e bug? It's not casual that this fs use an hw protection schema. I mean, this fs is not only a yet another fs, but a fs born with a specific target. So I think modifying a ramdisk to have these behaviors isn't a little modification. Marco -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
On Tue 2009-06-23 20:07:23, Marco wrote: Pavel Machek wrote: On Mon 2009-06-22 14:50:01, Tim Bird wrote: Pavel Machek wrote: block of fast non-volatile RAM that need to access data on it using a standard filesytem interface. Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are better with ext2. Not if you want the RAM-based filesystem to persist over a kernel invocation. Yes, you'll need to code Persistent, RAM-based _block_device_. First of all I have to say that I'd like to update the site and make it clearer but at the moment it's not possible because I'm not the admin and I've already asked to the sourceforge support to have this possibility. About the comments: sincerely I don't understand the comments. We have *already* a fs that takes care to remap a piace of ram (ram, sram, nvram, etc.), takes care of caching problems, takes care of write Well, it looks pramfs design is confused. 13MB/sec shows that caching _is_ useful for pramfs. So...? You are talked about journaling. This schema works well for a disk, but what about a piece of ram? What about a crazy kernel that write in that area for a bug? Do you remember for example the e1000e bug? It's not I believe you need both journaling *and* write protection. How do you handle power fault while writing data? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/14] Pramfs: Include files
On Tuesday 23 June 2009, David Woodhouse wrote: And dd on /dev/mem would work, surely? Actually, reading from /dev/mem is only valid on real RAM. If the nvram is part of an IO memory mapping, you have to do mmap()+memcpy() rather than read(). So dd won't do it, but it's still easy to read from user space. I'd definitely recommend making it fixed-endian. Not doing so for JFFS2 was a mistake I frequently regretted. Right. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How the kernel printk works before do console_setup.
Johnny Hung wrote: Hi All: I have a powerpc arch platform. The default console is ttyS1 not ttyS0 in the platform. My question is how the kernel print debug message like DBG before parse kernel command line and do console_setup function. The command line passed to kernel about console info is console=ttyS1. So kernel can not print anything before parse cmd line and initial console but the result is against. Anyone point me or give me a clue is appreciate. Before the console is set up, the printk data is formatted and put into the kernel log buffer, but not sent to any console. Any messages printk'ed before that are buffered but do not appear. When the console is initialized, then all buffered messages are sent to the console, and subsequent printks cause the message to go to the log buffer, but then immediately get sent from there to the console. Under certain conditions you can examine the log buffer of a kernel that failed to initialize it's console, after a warm reset of the machine, using the firmware memory dump command. See http://elinux.org/Kernel_Debugging_Tips#Accessing_the_printk_buffer_after_a_silent_hang_on_boot for some tips on accessing the log buffer of a previous boot. Note also, that if the serial console does not come up, but the kernel successfully boots, and you can get a network login on the machine, you can always print out the kernel log buffer messages using 'dmesg' at a user-space shell prompt. Hope this helps! -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
