Linux kernel thread with Linux 2.6.x
On Tue, 30 May 2006 11:46:09 +0200, Laurent Lagrange wrote: Thanks for your answer, but a tasklet runs in interrupt context (in_interrupt() != 0) so it doesn't support schedule() call included in down semaphore function. Do you have code you can show? J?rn -- Data expands to fill the space available for storage. -- Parkinson's Law
NAND and JFFS2 supports in Linux 2.4
On Thu, 13 April 2006 16:49:35 +0200, Laurent Lagrange wrote: -Message d'origine- De : Josh Boyer Linux 2.4.18 or 2.4.25 do not support this device, Those are entire too old. Except for some customers which must maintain kernels during many years :-) Linux 2.4.31 seems supporting this device but JFFS2 is not adapted, NAND + JFFS2 + 2.4 is not a supported combination. That's the problem i am facing with. Supporting an old system for years is one thing. Adding new features is a completely different beast. Looks like you have to spend some substantial time, just to get something running. Are you sure this is desired and preferred over a kernel upgrade? Might be worth rethinking. J?rn -- Those who come seeking peace without a treaty are plotting. -- Sun Tzu
Which way to store log in flash on mpc8xx?
On Mon, 19 September 2005 11:40:05 -0700, Shawn Jin wrote: This must be a very common task (to store logfiles in flash), but I just can't seem to find the right way to do it. Note that log files may cause a lot of trouble when using a JFFS2 file system. Youmay want to addd a buffering layer, like pramfs in a dedicated RAM area (SRAM ideally). What's the trouble caused by log files when using a JFFS2? I'm not aware of that. Any pointers to where I should look into are much appreciated. I guess this should become a FAQ item. JFFS2 creates one or more nodes whenever sys_write is called. Unbuffered log entries are usually quite small, so a single node is written. Let's assume the worst case, just for fun, writes of a single by. Now, each node is prepended by a struct jffs2_raw_inode of 64 bytes. So you're causing the first problem: 1. Up to 65x the raw file data is written to flash. Which means you waste bus bandwidth, was flash space and waste flash lifetime. After GC, most of those nodes should get combined to 4k nodes (plus 64 bytes for the header). Now, JFFS2 also requires an in-memory structure per node, the struct jffs2_raw_node_ref, weighing in at 16 or 24 bytes, if you have a 32bit or 64bit arch. Those will cost you precious memory: 2. Up to 24x the raw file data is required in DRAM. Next problem is with GC accounting. JFFS2 only differentiates between valid and obsolete data. After writing a huge logfile, all of its nodes are still valid. Therefore GC will never try to GC such nodes, unless they happen to sit in an erase block with a lot of obsolete data. And even then, they could get copied as-is, with no combining. 3. JFFS2 GC is too stupid to detect miniature nodes and combine them. So, your problem 1 and 2 will not go away if you wait long enough. Renaming the log file also won't help. The only cure would be to *copy* it to the new location and delete the original file afterwards. Or - alternatively - to fix JFFS2 GC and send a patch. Or - as already proposed - by writing in larger chunks in the first place. If you decide to fix JFFS2 GC, I'd be happy to review the patches and merge them if deemed worthy. J?rn -- My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. -- Edsger W. Dijkstra
[RFC PATCH 1/4] PHY Abstraction Layer III (now with more splitiness)
On Wed, 27 July 2005 14:34:19 -0700, Randy Dunlap wrote: Ok, here I won't agree to disagree with you. !foo as a check for NULL is a reasonable idea, but not my style. If that's the preferred style for the kernel, I will do that. But (var == constant) is a style that asks for errors. By putting the constant first in these checks, you never run the risk of leaving a bug like this: if (dev = NULL) ... This kind of error is quite frustrating to detect, and the eye will often miss it when scanning for errors. If you follow constant == var, though, then the bug looks like this: if (NULL = dev) which is instantly caught by the compiler. Just my 32 cents Yes, we know about that argument. :) The counter-argument basically goes like this: 1. All relevant compilers (GCC) warn on if (dev = NULL), so you will only miss the bug if you ignore compiler warnings. Ignoring compiler warnings is not generally endorsed by the kernel crowd. 2. Very hard to read, if (NULL = dev) is. Reversing the order is a fun thing to do for small green characters in fantasy and scifi stories and fairly popular in peotry as well. But understanding the meaning of reverse order sentences takes more time. In the kernel, peer review is an important aspect and making the code hard to read hurts peer review. And maybe you can add another one: 3. Im my personal experience, reverse order comparisons were a good indicator of buggy code. J?rn -- Schr?dinger's cat is BLINKnot/BLINK dead. -- Illiad
linux and sram
On Wed, 13 July 2005 22:34:09 +0200, Wolfgang Denk wrote: In message 20050713153231.GA17534 at mail19d.g19.rapidsite.net you wrote: If we are using U-boot and populate the CFG_SRAM_SIZE and CFG_SRAM_BASE values, and makes sure this is passed into the kernel. Does Linux 2.4.2x+ have any direct support for this? Is it just added into the regular memory pool? Does it get used for specific tasks? The standard Linux kernel knows nothing about SRAM. Or is this set aside for custom drivers? Indeed. You need a driver to support SRAM. Some people use slram/phram for that purpose. It creates an mtd (memory technology device) which can be translated into either a block or a char device. Quite sufficient for most uses. J?rn -- To announce that there must be no criticism of the President, or that we are to stand by the President, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt, Kansas City Star, 1918
mtd mount problem
On Thu, 21 April 2005 15:02:48 +0200, Marco Schramel wrote: /dev # date /dev/mtd1 MTD_open MTD_ioctl MTD_write MTD do_write_buffer(): software timeout ^ ERROR ERROR ERROR ERROR ERROR ERROR ERROR This only occurs if i write the second time to the flash memory without erasing it before. That's harmless. Flash is a write-once medium between erases. Your setup appears sane in principle, so there must me a subtle mistake you made (bugs are out of the question of course ;). Missing a real howto, let me run through the sequence: 1. Erase the flash partition. Either o eraseall /dev/mtdX or o cat file_filled_with_0xff /dev/mtdblockX 2. Do *not* write anything to it afterwards. Jffs2 would just error out. 3. Mount jffs2. Either o mount mtdX -t jffs2 mount_point or o mount /dev/mtdblockX -t jffs2 mount_point J?rn -- The grand essentials of happiness are: something to do, something to love, and something to hope for. -- Allan K. Chalmers
mtd mount problem
On Thu, 21 April 2005 18:55:52 -0700, Eugene Surovegin wrote: On Thu, Apr 21, 2005 at 06:53:37PM -0700, Eugene Surovegin wrote: On Fri, Apr 22, 2005 at 03:31:34AM +0200, J?rn Engel wrote: [snip] 1. Erase the flash partition. Either o eraseall /dev/mtdX or o cat file_filled_with_0xff /dev/mtdblockX Huh? I fail to see how options you listed are equivalent. By cating file filled with 0xff you cannot erase flash, period. Only eraseall (or erase, if partition occupies 1 erase block) flash can be erased. Oops, sorry, I failed to notice /dev/mtdblockX. Stupid me. Ignore this noise. Btw, I've also written a tool called 'ff' once. It will simply write tons of 0xff to stdout. Rewriting the thing from scratch should be slightly faster than me trying to look for the source (about 4 lines of code?). J?rn -- My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. -- Edsger W. Dijkstra
MTD Mapping driver - out of vmalloc space
On Tue, 12 April 2005 11:07:38 +0100, Chris Elston wrote: Thanks for everyone's input on this, I've moved the kernel virtual base address to 0xa000, and it works fine now. I'm still not convinced that this is a future proof solution though. What happens when I get a board with 512MB Flash 1GB SDRAM? I can push the top of the SDRAM out to the high mem area, but I'll have to encroach further into user space to map the Flash. There's no good reason that the whole of the Flash need be mapped at the same time. (Perhaps performance?) Definitely performance. At the end of the day, you need a bigger namespace of some sorts. Possible solutions are: o a 64bit machine, o a 4GiB/4GiB kernel/user split and o a PPC440 with 36bit addressing and some hardware and ioremap tricks to move flash above the 32bit limit. The 4/4 split also costs some performance. It doesn't violate the 'flash read must be atomic' requirement, though. J?rn -- ...one more straw can't possibly matter... -- Kirby Bakken
mtd maps
On Tue, 15 March 2005 19:33:33 -0600, Josh Boyer wrote: There is a driver in MTD CVS now called mphysmap (untested I believe), that might be able to deal with that. Eventually. If someone has the need and a test machine with remote access, it could get done rather soon. J?rn -- Beware of bugs in the above code; I have only proved it correct, but not tried it. -- Donald Knuth
[PATCH 2.6.12] mtd: Remove MTD map file for Chestnut platform.
On Fri, 11 March 2005 17:40:55 -0700, Mark A. Greer wrote: Remove Chestnut mtd map file. The chestnut now sets up its MTD map from its platform-specific file so the map file drivers/mtd/maps/chestnut.c is no longer needed. This patch removes the file the Kconfig/Makefile hooks. Please apply. Applied to mtd cvs. It will make its way to Linus eventually... Thanks! J?rn -- Sometimes, asking the right question is already the answer. -- Unknown
Building a Kernel for the AMCC PPC440EP Bamboo Board
On Thu, 3 March 2005 09:23:22 +0100, Gerhard Jaeger wrote: Could not confirm that so far! Ebony and Ocotea are working out of the box, using these defconfig files! (pristine kernel 2.6.11) With PIBS and on a bamboo? If I was just too stupid and made some silly mistake, that would be great news. J?rn -- I don't understand it. Nobody does. -- Richard P. Feynman
Building a Kernel for the AMCC PPC440EP Bamboo Board
On Fri, 4 March 2005 08:39:22 -0700, Matt Porter wrote: Impossible. You need a 440EP/Bamboo specific port. Memory map is completely different on 440EP. For discussion sake, note that 440GP/GX are very similar parts with respect to memory map and peripherals, then 440SP and 440EP each have very different layouts. Right. FWIW, there's somebody well into a 2.6 440EP port, dunno what the ETA on submitting the code is. Would be nice to get either somebody's name or the preliminary code. I don't care about crashes too much (can't be worse than not working at all) and am willing to help. If neither is realistic - heck, we need to get familiar with the cpu anyway, so there is no reason not to race for submission. ;) J?rn -- A surrounded army must be given a way out. -- Sun Tzu
Building a Kernel for the AMCC PPC440EP Bamboo Board
On Tue, 1 March 2005 17:37:22 +0100, Gerhard Jaeger wrote: On Tuesday 01 March 2005 17:14, Zeighami, Roy wrote: When I select 44x as the CPU type, I don't see Bamboo under machine type. This won't work, as Bamboo BSP stuff is currently not added. Correct. Any suggestions? try to use ebony_defconfig Doesn't work, neither does ocotea. Both are able to display TUX! on the dot-matrix display, but panic before writing any serial output. /me has one of these beauties as well and will try to hack up support for it. If anyone has patches or suggestions, help is always appreciated. J?rn -- Simplicity is prerequisite for reliability. -- Edsger W. Dijkstra
consistent_alloc() on PPC
On Wed, 19 January 2005 17:23:42 +0530, Sachin P wrote:
I am facing some problems porting my drivers to the PPC platform . Am
currently using consistent_alloc() and consistent_free() to
allocate/free (non-cached) DMA ble memory.
Is there any function/patch/macro, equivalent to
phy_to_virt()/virt_to_phy() for memory returned by consistent_alloc()?
Imo not. I ended up writing a private version of it, along these
lines:
static inline unsigned long private_io_to_bus(void *addr)
{
return iopa((unsigned long)addr) + offset;
}
Wouldn't hurt if you could generalize it somehow.
J?rn
--
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
[RFC] Patch to Abstract Ethernet PHY support (using driver model)
On Fri, 14 January 2005 15:00:20 -0600, Andy Fleming wrote: Wrt. the proposed PHY lib, I agree. Didn't even bother to look at the code, it's mere size said enough. Ok, this time I did bother to look at the code... Hmm... Before I spend too much time revising based on previous comments ebs made, is there a general consensus that the code is much too large? I know there's a lot in there, but the goal is to simplify PHY management for all ethernet drivers, new and old, and thus reduce code size, overall. Is this code heading in the right direction? Does it do too much? Too little? drivers/net/Kconfig | 33 +- drivers/net/Makefile |3 drivers/net/phy/Kconfig | 45 +++ drivers/net/phy/Makefile |9 drivers/net/phy/cicada.c | 165 +++ drivers/net/phy/davicom.c| 277 +++ drivers/net/phy/lxt.c| 237 + drivers/net/phy/marvell.c| 173 drivers/net/phy/mdio_bus.c | 173 drivers/net/phy/phy.c| 512 drivers/net/phy/phy_device.c | 598 +++ drivers/net/phy/qsemi.c | 183 + include/linux/phy.h | 355 + 13 files changed, 2743 insertions(+), 20 deletions(-) Imo, the general idea to combine phy code makes sense - to a degree. Advantage is less code copied over most existing drivers. But few people have more than one driver compiled in (or loaded, in case of modules) at a time, so that bloat is source code only. The big danger here is that real compiled kernels will actually grow. As an example, drivers that don't bother with suspend/resume should have a slightly smaller binary, compared to generic code that supports it. There are valid reasons why people might want such a device, so no size fits 'em all. If you manage to convert existing drivers to your new proposed model, you can show some numbers. Is the compiled kernel smaller or bigger after your changes. About the same? If there is significant growth, I'm pretty unexcited about the idea. If it shrinks, you're a genius and sure, the patch should go in. With roughly the same binary size, you can point to code size and show how that has decreased. Right now, all I see is more code and I get this feeling that binary size will grow as well. So please try to prove me wrong. J?rn -- Time? What's that? Time is only worth what you do with it. -- Theo de Raadt
[RFC] Patch to Abstract Ethernet PHY support (using driver model)
On Thu, 13 January 2005 17:00:16 -0800, Eugene Surovegin wrote: On Thu, Jan 13, 2005 at 10:58:08PM +0100, J?rn Engel wrote: http://www.broadcom.com/collateral/pb/5325-PB05-R.pdf With some thinking and very little code, you can use this neat chip almost like a normal phy. Yeah, but why would I want to? If you connect your MAC to any 5 PHYs my statement still stands, if directly to MII you don't need any PHY stuff at all, because link is always ON and speed/duplex is fixed. In fact, we use different switch chips connected to PPC4xx directly. In this situation, in my NAPI IBM EMAC driver I just have special PHY-less case which is trivial fixed settings one. And all this PHY lib is completely unneeded bloat. Wrt. the proposed PHY lib, I agree. Didn't even bother to look at the code, it's mere size said enough. But an abstraction different from drivers/net/mii.c is needed to handle the 5325 chip. Or, you could have the special cases all over in your code, but that's a) ugly and b) more code. I used to have such a mess and after doing the proper abstraction, it line count went down. J?rn -- Time? What's that? Time is only worth what you do with it. -- Theo de Raadt
[RFC] Patch to Abstract Ethernet PHY support (using driver model)
On Fri, 14 January 2005 07:25:18 -0800, Eugene Surovegin wrote: On Fri, Jan 14, 2005 at 03:55:18PM +0100, J?rn Engel wrote: Wrt. the proposed PHY lib, I agree. Didn't even bother to look at the code, it's mere size said enough. But an abstraction different from drivers/net/mii.c is needed to handle the 5325 chip. Or, you could have the special cases all over in your code, but that's a) ugly and b) more code. I used to have such a mess and after doing the proper abstraction, it line count went down. Well, I still fail to see what is so _special_ about this chip that it needs proper abstraction. Could you elaborate, please? The way I handled this in my drivers was clean and simple - there-is-no-PHY. And this wasn't in any case chip-specific and was set up through OCP in board support code. So I'm kinda puzzled what ugliness and more code you are talking about. We can also make a fake PHY which will always indicate link, will have fixed speed/duplex capabilities and will not support autoneg. If you think this is more elegant, OK, I might even agree with you :). Exactly. You need link status, speed and duplex status at the least. Put query functions for those three into a struct phy_ops or whatever it may be called and you're done. Depending on your hardware, you may also need something more complicated for various fixups, etc. But it's mostly those three functions. Please, note that wrt current discussion we are interested only in CPU port, not other 5 ports which aren't connected to the CPU at all. This is completely different stuff and yes, if we want to expose them in some way we need another abstraction. But abstraction of switch chips is a big and complex thing - they are very different, and frankly this one you mentioned is quite feature-challenged and will not make a good model chip IMHO :). Well, it's one of the few I've had to worry about so far. I'm a big non-believer in abstractions I just don't need yet. The one outlined above I already needed. J?rn -- To announce that there must be no criticism of the President, or that we are to stand by the President, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt, Kansas City Star, 1918
[RFC] Patch to Abstract Ethernet PHY support (using driver model)
On Thu, 13 January 2005 13:21:52 -0800, Eugene Surovegin wrote: It's a standard, period. If there is a PHY which isn't compliant I guess it will not work anyway, but in this case, yes, we can use PHY-specific link detection, but only in this case. I suspect you'll have a hard time finding such PHY :) http://www.broadcom.com/collateral/pb/5325-PB05-R.pdf With some thinking and very little code, you can use this neat chip almost like a normal phy. J?rn -- Optimizations always bust things, because all optimizations are, in the long haul, a form of cheating, and cheaters eventually get caught. -- Larry Wall
