Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
Le Wed, 03 Jun 2009 12:19:57 -0400, James Bottomley james.bottom...@hansenpartnership.com a écrit : So ZONE_DMA and coherent memory allocation as represented by the coherent mask are really totally separate things. The idea of ZONE_DMA was really that if you had an ISA device, allocations from ZONE_DMA would be able to access the allocated memory without bouncing. Since ISA is really going away, this definition has been hijacked. If your problem is just that you need memory allocated on a certain physical mask and neither GFP_DMA or GFP_DMA32 cut it for you, then we could revisit the kmalloc_mask() proposal again ... but the consensus last time was that no-one really had a compelling use case that couldn't be covered by GFP_DMA32. Back a few years ago, I was working on a MIPS platform which had 256 MB of RAM attached to the CPU memory controller and 128 MB attached to an external memory controller. The layout of the memories was: 256 MB CPU-attached memory first, and then the 128 MB external-controller-attached memory. Now, back to the DMA discussion: the Ethernet controller, which was part of that external controller also driving the 128 MB bank of memory, could only DMA to and from memory controlled by that same controller (i.e only to the *top* 128 MB of the physical address space). I'm by far not an mm expert, but as far as I could understand the zone mechanism, it was not possible to describe such a physical memory configuration where DMA-able memory is only at the top. In the end, I ended up passing mem=..., managing manually a few megabytes of memory at the top of the physical address space, and hacking the Ethernet driver to copy back and forth the skb contents between the main memory and the DMA-reserved memory. So when Calatalin Marinas says « currently ZONE_DMA is assumed to be in the bottom part of the memory which isn't always the case », I cannot agree more. Reference: http://www.linux-mips.org/archives/linux-mips/2004-09/msg00152.html Sincerly, Thomas -- Thomas Petazzoni, 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: Representing Embedded Architectures at the Kernel Summit
On Jun 2, 2009, at 5:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: I'd like to propose AMP and kernel relocate as more and SoC will came with multiple core with or without the same arch I think AMP or at least the idea of the kernel communicating with other OSes on the same SoC in multi-core systems is interesting. - k -- 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
Kernel crashing and log buffers...
On 17 Oct 2007, after much discussion and debate, Mike added add two new functions for reading the kernel log buffer (from kernel space). http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0b15d04af3dd996035d8fa81fc849d049171f9c3 The intention was for them to be used by recovery/dump/debug code so the kernel log can be easily retrieved/parsed by the bootloader (or another kernel) in a crash scenario. I was going to push the arch specific recovery/dump/debug code that uses them upstream (yeah, it has been a little while - but anyway...) it was removed since then by Roel Kluin ... 21 Oct 2008: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=acff181d3574244e651913df77332e897b88bff4 Before I ask Andrew to add it back, I thought I would make sure it was still a useful function, and did everything everyone wanted - and wasn't deemed unnecessary by a feature/function that I wasn't aware of - like the next thing... I saw the patch Grant sent recently - Add Alternative Log Buffer Support for printk Messages (in Nov2008 to the embedded list, and Jan 2009 to lkml) - but I couldn't find any followups - and it doesn't seem to be in Linus's tree. http://thread.gmane.org/gmane.linux.kernel.embedded/1358/focus=1373 http://lkml.org/lkml/2009/1/21/250 I can see the desire on Wolfgang Grant's part - for not needing the copy from/to - (you never have to worry about crashing nicely - the kernel panics, but you still need to copy memory around - potentially causing all kinds of secondary issues - and masking the real reason the crash occurred). But for the majority of the case - the copy from/to would work much better than what we have in mainstream today... I would be interested in Paul and Russell - how have you solved this issue? (Or do your kernel's never crash? :) Thanks -Robin -- 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
AT91SAM9G20 design and boot times
Hi, we're designing our next generation RFID reader and I'm planning on using the AT91SAM9G20 in the next design. We currently use the AT91RM9200. Can I get some feedback from people with regards to general design configurations that affect the boot time with respect to this CPU (or the AT91SAM9260) Some questions are: * what is your boot time? What is the time from power-on to kernel running, how long does the kernel take to run until init starts, and how long does init take? * what is your system hardware configuration? CPU+NAND, CPU+NOR+NAND, CPU+DATAFLASH+NAND? * do you boot everything from the NAND or do you use a combination of Dataflash/NOR and NAND? * do you use U-Boot, or a minimal custom bootloader that copies a kernel image from NAND to SDRAM and then executes it? * do you mount a small partition of the NAND to begin with and then mount the rest later? * do you have a monolithic kernel, or is it split into minimal with modules loaded from, say, JFFS2 on NAND? * are you using JFFS2 or UBIFS? Any info is much appreciated, thank you! regards, Aras Vaichas -- 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
