Re: I:Re: [PATCH 06/14] Pramfs: Include files
On Tue, 23 June 2009 19:38:33 +0200, Marco wrote: 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. Glancing at the discussion with Pawel, I see two paths to follow. One is to turn pramfs into a full-features all-round general-purpose filesystem with mkfs, fsck, xattr and any number of additional features. That way lies doom, as you would compete against ext2+xip and have little new to offer. The other path is to make/keep pramfs as simple as possible for comparatively specialized purposes, like flight recorder data and dump information. Main selling point here is the amount of vulnerable code in the total package. ext2 + block layer + vfs helpers is relatively large and many things may go wrong in a panic situation. So I agree with you that many things expected from general purpose filesystems simply don't apply to pramfs. Moving mkfs into the kernel is a fair tradeoff, when the required code is small. Endianness is a different case imo. dd may not work, but a jtag probe will happily get you the dump to your development machine. I quite agree, but I'd like to say that it was _not_ my intention to submit a general-purpose fs comparable with ext2 or ext3. And even within the same box you can have more than one architecture and endianness. http://www.top500.org/system/9707 will show you one such beast, which happens to have the top bragging rights at the moment. I don't want to endorse such strange beasts, but there is no good reason not to support reading the ppc-written fs from the opteron. In fact, there is no reason full stop. Jörn MmmJtag dump makes more sense, ok in the next release I rework the layout to have an independent endianess layout. 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 06/14] Pramfs: Include files
2009/6/23 Arnd Bergmann a...@arndb.de: 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. For security reasons pram reserve the region of memory with reserve_mem_region_exclusive(). 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
Using UART in kernel driver code on AT91SAM9260
Hi, I have a speech codec chip which uses SPI for high-speed PCM data and UART for control/compressed speech packet transfer. While I could write a userland device driver that just uses the ttySn serial device, I would prefer to do that in kernel space since this is where device drivers belong. This way a device could be created where compressed speech packets can be read and written. Possible device setup functions could be done with IOCTLs. Now what is the best way to implement this ? There is the linux/drivers/char/atmel_serial.c driver which I could modify, so that it also includes the driver code for the speech codec. However, obviously that would be a really bad idea since it would duplicate code and completely bypass the linux serial port abstraction layer. It would be better to somehow write a speech codec driver that depends on the UART driver. Thus on the speech codec serial port no ttySn device should be created by the UART driver, but instead the speech codec driver should create the device (e.g. /dev/speechcodec0). Since the speech codec driver should only do speech codec specific tasks, it should use the UART driver to send and receive data over the serial port. I suppose this it is a common problem that higher level kernel driver code would like to use lower level driver code. For example there is the GPIO driver which enables high level kernel code to use GPIO pins. It's the same for other communication interfaces like I2C or SPI. However, these drivers usually do not create a device, but they rather export kernel symbols which can then be used by higher level kernel code. Unfortunately, it doesn't seem like the relevant serial port function symbols are exported ? On mach-at91 it seems like the UART can be registered by calling the relevant setup function in linux/arch/arm/mach-at91/at91sam9260_devices.c which is at91_register_uart(). However, once I register an uart port, also a ttySn device is created (which I do not want). By looking at linux/documentation/serial/driver it seems like bypassing linux/drivers/serial/serial_core.c seems to be the right way since the low level linux/drivers/serial/atmel_serial.c already provides the necessary UART ops in struct uart_ops. However, these uart_ops are not exported, so I don't know how to access them. Is this the right way to go ? How could I use the low level driver but bypass serial_core ? It would be great if you could provide some links to documentation and example code. cheers, Stefan -- 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: Using UART in kernel driver code on AT91SAM9260
Stefan Schoenleitner wrote: It would be great if you could provide some links to documentation and example code. I just found out that there are other kernel drivers using the serial port as well (e.g. the SLIP or PPP drivers). It seems that what I want to do (which is accessing the serial port from kernel space) is called a line discipline. I found an article Writing a Kernel Line Discipline with code snippets on http://www.linux-mag.com/id/1891 (You can find a login to this page here: http://www.bugmenot.com) Is this the right way to go ? -- 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: Using UART in kernel driver code on AT91SAM9260
Stefan == Stefan Schoenleitner dev.c0deb...@gmail.com writes:
Hi,
Stefan There is the linux/drivers/char/atmel_serial.c driver which I
Stefan could modify, so that it also includes the driver code for
Stefan the speech codec. However, obviously that would be a really
Stefan bad idea since it would duplicate code and completely bypass
Stefan the linux serial port abstraction layer.
Stefan It would be better to somehow write a speech codec driver
Stefan that depends on the UART driver. Thus on the speech codec
Stefan serial port no ttySn device should be created by the UART
Stefan driver, but instead the speech codec driver should create the
Stefan device (e.g. /dev/speechcodec0). Since the speech codec
Stefan driver should only do speech codec specific tasks, it should
Stefan use the UART driver to send and receive data over the serial
Stefan port.
The input layer has serio infrastructure for this (E.G. for serial
mice/touchscreens). Now, a speech codec doesn't have much to do with
input devices, but it atleast clearly seperates the lowlevel uart
communication from the speech codec handling.
Have a look in drivers/input/{serio,touchscreen}.
--
Bye, Peter Korsgaard
--
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: Using UART in kernel driver code on AT91SAM9260
Hi,
Peter Korsgaard wrote:
The input layer has serio infrastructure for this (E.G. for serial
mice/touchscreens). Now, a speech codec doesn't have much to do with
input devices, but it atleast clearly seperates the lowlevel uart
communication from the speech codec handling.
Have a look in drivers/input/{serio,touchscreen}.
thanks for the tip !
I'm looking to find some more serio documentation now.
If it won't work out, I guess I still have the possibility to write a
line discipline.
However, using serio seems to be more comfortable (also from a useeland
perspective).
cheers,
stefan
--
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_. 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...? caching problems means to avoid filesystem corruption, so dirty pages in the page cache are not allowed to be written back to the backing-store RAM. It's clear that there is a performance penalty. This penalty should be reduced by the access speed of the RAM, however the performance are not important for this special fs as Tim Bird said, so this question is not relevant for me. If this issue is not clear enough on the web site, I hope I can update the information in the future. 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 Ah now the write protection is a needed feature, in your previous comment you talked about why not use ext2/3... 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 06/14] Pramfs: Include files
Arnd Bergmann wrote: On Wednesday 24 June 2009, Marco Stornelli wrote: 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. For security reasons pram reserve the region of memory with reserve_mem_region_exclusive(). That will only prevent other device drivers from stepping on it, /dev/mem does not care about mem_region reservations. Arnd Userland may not map this resource, so /dev/mem and the sysfs MMIO access will not be allowed. This restriction depends on STRICT_DEVMEM option. It's true that currently is only implemented in the x86 world. 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
Marco wrote: Second question: what happens if the system crashing _during_ a write to a file. Does it mean that file will fail it's checksum when it's read at the next boot? Maybe files aren't so important. What about when you write a file, and then rename it over an existing file to replace it. (E.g. a config file), and the system crashes _during_ the rename? At the next boot, is it guaranteed to see either the old or the new file, or can the directory be corrupt / fail it's checksum? First of all I have to explain better the current policy: the checksum works at inode and superblock level and currently there isn't a recovery function as the journaling. About the superblock it's easy to use a redundant policy to be more robust. To be honest, superblock robustness is less of a concern. The real concern is losing file or directory contents, so it can't be used to store persistent configuration data, only debugging logs. About the inode, at the moment when the checksum doesn't match the inode it's marked as bad calling the function make_bad_inode(). Let's see if I understand right. If it lose power when writing to a file, after boot the file is likely to be marked bad and so return -EIO instead of any file contents? If it loses power when doing atomic rename (to replace config files, for example), it's likely that the whole /pramfs/configs/ directory will be corrupt, because the rename is writing to the directory inode, so you lose access to all names in that directory? That sounds like it can't be used for persistent configuration data. If a directory is marked as bad, or a file-inode in it is marked bad, can you even rmdir it to clean up and start again? Thanks, -- Jamie -- 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_. 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...? caching problems means to avoid filesystem corruption, so dirty pages in the page cache are not allowed to be written back to the backing-store RAM. It's clear that there is a performance penalty. This penalty should be reduced by the access speed of the RAM, however the performance are not important for this special fs as Tim Bird said, so this question is not relevant for me. If this issue is not clear enough on the web site, I hope I can update the information in the future. 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 Ah now the write protection is a needed feature, in your previous comment you talked about why not use ext2/3... Marco Just for your information I tried the same test with pc in a virtual machine with 32MB of RAM: Version 1.03e --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP hostname 15M:1k 14156 99 128779 100 92240 100 11669 100 166242 99 80058 82 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 4 2842 99 133506 104 45088 101 2787 99 79581 101 58212 102 These data are the proof of the importance of the environment, workload and so on when we talk about benchmark. Your consideration are really superficial. 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 Tue 2009-06-23 20:07:23, Marco wrote: 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? I think this is basically right. write protection for the crazy kernels, and journalling for powerfail/crash during updates. Journalling can be extremely simple. It can be just one memory block at a fixed location, double-buffering all writes. Pramfs already has checksums, which makes that easier. You just write to the buffer area first, with checksum, then write to the final area. Mount looks at the buffer area, and if the checksum is fine, copies the contents to the destination block. That's all it takes to be resistant against power failures and crashes during writes. Probably 100 lines of code. -- Jamie -- 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 Wed 2009-06-24 18:49:11, 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...? caching problems means to avoid filesystem corruption, so dirty pages in the page cache are not allowed to be written back to the backing-store RAM. It's clear that there is a performance penalty. This penalty should be reduced by the access speed of the RAM, however the performance are not important for this special fs as Tim Bird said, so this question is not relevant for me. If this issue is not clear enough on the web site, I hope I can update the information in the future. Yes, please update the pages... 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? Ah now the write protection is a needed feature, in your previous comment you talked about why not use ext2/3... write protection should be handled at block device layer, not filesystem layer. So yes, use ext2. You still did not explain how you avoid the need for journalling... 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
Status of bzip2 and lzma kernel compression for ARM?
Hi Alain, I would like to test bzip2 and lzma compression on ARM. Would you mind telling me what the status of your patches on ARM is, now that the x86 and architecture independent code has been merged? Have you or has anyone already updated them for 2.6.30, or shall I update them by myself? Thank you in advance, Cheers, Michael. -- Michael Opdenacker, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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.
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. On ppc, we have tricks to display things earlier :-) We can initialize the serial ports way before console_setup() (and we do in most cases) and we use what we call the udbg console until the real one takes over. The udbg console is a very small layer which outputs via a provided putc routine. Platforms can provide their own here, we have a collection of standard ones for legacy UARTs (it should be automatically setup in that case by the code in legacy_serial), Apple ESCCs, etc... We even have compile time options that allow that stuff to be initialized before start_kernel... Cheers, Ben. 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 = ___ Linuxppc-dev mailing list linuxppc-...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- 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
