Re: [RFC PATCH] arm: drop Execute-In-Place
On 16:31 Thu 05 May , Mike Frysinger wrote: > On Thu, May 5, 2011 at 16:25, Tim Bird wrote: > > On 05/05/2011 12:27 PM, Mike Frysinger wrote: > >> On Thu, May 5, 2011 at 15:12, Tim Bird wrote: > >>> As for in-tree-ness - I thought the most recent message was to stay > >>> out of tree until the refactoring was over. ;-) > >> > >> to be fair, does this have any relevance whatsoever to NEC parts ? > >> istm that the hindrance here is NEC doing any actual work for > >> mainline. even if there was no refactoring, i find it hard to believe > >> that an NEC port would be posted. if it were actually something that > >> could happen, then they should already be posting patches for *basic* > >> review to get the pieces unrelated to the refactoring worked out. > >> there's no reason this has to be done serially. > > > > Well, OK. I just don't want to lob bombs at NEC and then > > have some poor soul over there get immediately rebuffed, due to > > basic ARM churn. Maybe not having naviengine support upstream > > is my fault, but Sony doesn't make the CPU, so it doesn't seem > > like it should be my job to mainline the chip support. About > > the only thing I have at my disposal is pressure not to buy > > the chip (but this is harder to exercise than one might think.) > > i dont have any vested interest either way wrt NEC or ARM/XIP. i was > just trying to highlight what i saw as a red herring. > > i think the axiom "post early & post often" holds just as true here. I've the same felling as Mike or David Out of tree does not exist Specially when they do effort to come mainline Best Regards, J. -- 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: AT91SAM9G20 design and boot times
On 14:48 Thu 11 Jun , Nicolas Ferre wrote: > Hi, > > Aras Vaichas : > > 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. > > Good choice ;-) > > > 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) > > I presume that you already know what are the configurations we are using > at Linux4sam.org on our at91sam9g20ek board. Anyway, I answer your > questions as it may also interest other readers. > > > 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? > > We have not tried to be clever on speeding up boot process but I guess > that we can save time: > - removing unneeded bootloader steps (remove u-boot for instance) > - removing unused drivers > - lower timeouts (Ethernet phy detection for example) > - tailor rootfs exactly to your needs > > That said, here are numbers from our not optimized demo > (AT91Bootstrap+u-boot+linux+buildroot): > - ~6s to Linux (can certainly be optimized) > - ~+2s to init > - ~+5s to login (here also) I've done some test on 9263 with the following config cpu+nor (u-boot+linux+busybox) ~4/5s to the prompt if the boottime is critical I'll recommend you NOR + XIP > > > * what is your system hardware configuration? CPU+NAND, CPU+NOR+NAND, > > CPU+DATAFLASH+NAND? > > CPU + NAND can lower your BOM > > > * do you boot everything from the NAND or do you use a combination of > > Dataflash/NOR and NAND? I've test it on 9263 > > Both. > > > * do you use U-Boot, or a minimal custom bootloader that copies a > > kernel image from NAND to SDRAM and then executes it? > > If boot time is a hot topic, choose AT91Bootstrap that directly loads Linux. I disagree on this because you will loose a lot's of possibity as bootcount DFU, store your kernel in your rootfs etc... > > > * do you mount a small partition of the NAND to begin with and then > > mount the rest later? > I'll consider to switch to UBIFS and use lzma compression (for the uImage) if no XIP Best Regards, J. -- 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: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
> > * Asymmetric MP: > * Different CPU frequencies > * Different CPU features (e.g. floating point only one > some CPUs): scheduler awareness, per-CPU hwcap bits (in > case user space wants to set the affinity) > * Asymmetric workload balancing for power consumption (may > be better to load 1 CPU at 60% than 4 at 15%) I'll add * Different Core ARCH * FDT or similar to describe I/O (MEM, PCI, GPIO) acessible for each instance * Mailbox Architecture * boot preocedure (bootloader as example done by Kumar Gala for the mpc8572ds in linux & U-Boot) * sharing rootfs (RO) (reduce the rootfs size on embedded) Best Regards, J. -- 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 13:29 Tue 02 Jun , Josh Boyer wrote: > On Tue, Jun 02, 2009 at 03:22:20PM +, James Bottomley wrote: > >Hi All, > > > >We've got to the point where there are simply too many embedded > >architectures to invite all the arch maintainers to the kernel summit. > >So, this year, we thought we'd do embedded via topic driven invitations > >instead. So what we're looking for is a proposal to discuss the issues > >most affecting embedded architectures, or preview any features affecting > >the main kernel which embedded architectures might need ... or any other > >topics from embedded architectures which might need discussion or > >debate. If you'd like to do this, could you either reply to this email, > >or send proposals to: > > > >ksummit-2009-disc...@lists.linux-foundation.org > > For those not following the ksummit list, below is the current list of > suggested topics: > > PROPOSERTOPIC > > Jon Corbet How much do we owe sloppy application writers > Jon Corbet The containers end game and how we get there > Balbir SinghThe Hacking Hour > Rafael Wysocki Regression tracking and kernel quality > Jon Corbet Criteria for acceptance of kernel tracepoints > Jesse BarnesProfiling and performance counters > Eric Biederman Procedures for dealing with patent problems > John Linville Patch review checklist > Matthew Wilcox How to handle style-only patches > Dan WilliamsRAID unification / stacked block devices > Jiri Kosina User-space drivers - worth encouraging? > Sam RavnborgShipping user-space components in the kernel > Kay Sievers Establishment/maintenance of per-subsystem todo lists > Steve Rostedt Improving changelogs > Jon Corbet I/O bandwidth controllers (maybe minisummit report) > Ted Ts'oPulseAudio and kernel interface issues > Greg KH Generic architecture support and arch layer cleanup > (Josh Boyer: add device tree discussion?) > Dave Jones cpumasks, churn, and unending API changes > Dirk HohndelIssues related to wireless technologies > Jon Corbet Tracing: > Merging utrace > Ftrace mainline v. private debugging tools > Non-ftrace visibility infrastructure > Systemtap for kernel developers > Marcel Holtmann Tracing and protocol dumping I'd like to propose AMP and kernel relocate as more and SoC will came with multiple core with or without the same arch Best Regards, J. -- 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: LZMA inclusion
> The primary compression algorithm of the .xz format is LZMA2. It fixes > some practical problems of the original LZMA. The .xz format also > supports filters for executable data (x86, ARM and a few others), which > combined with LZMA2 usually improve compression ratio 5-10 % over plain > LZMA or LZMA2. I suppose such filters would be useful in the kernel, > since the kernel image and iniramfs contain mostly executable code. > > Final version of the .xz format specification will be released in this > month. I try to get the first stable release or at least a good beta > release of the xz package out in this month too. > > Once the stable release of the xz package is out, I could be willing to > write an easy-to-use .xz decoder that is suitable for inclusion to > Linux (including proper coding style with comments). I have understood, > that for kernel and initramfs compression as well as for SquashFS, it > would be enough to support single-call buffer-to-buffer decoding > (comparable to uncompress() in zlib). Such code can be significantly > simpler than stateful multi-call implementation. This sound very good. Please note that we also use it in U-Boot so if could help us to have it also in it. It will be usefull Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: initrd and uImage
On 09:42 Fri 08 Aug , Fundu wrote: > Hi, > First off i have a ppc based board. > and i'm trying to load a kernel image with ramdisk rootfs. Which version of U-Boot do you use? Which features do you enable? > > i have build the kernel. it spit uImage,zImage and vmlinux.gz > > my question are. > 1) what are all the different image types ? > i know the uImage is just the kernel, what are the rest (zImage & vmlinux.gz)? > > 2) i'm using u-boot as the bootldr. so i download the uImage (cause zImage > and vmlinux.gz aren't bootlable) from tftp server and then do bootm > the kernel only load partially. How does the kernel know where/how to load > the rootfs ? It's depend on which uImage you use. In U-Boot, you can generate a Multi-File Image with the ramdisk inside, FDT, multiple configuration etc... In the case you describe you are supposed to download the ramdisk via tftp also and set the kernel parameter via the bootargs variable and do bootm. example U-Boot> tftp 20 uImage U-Boot> tftp a0 uRamdisk U-Boot> bootm 20 a0 good examples on these pages http://www.denx.de/wiki/view/DULG/Manual http://www.denx.de/wiki/view/DULG/RootFileSystemOnARamdisk http://www.denx.de/wiki/view/DULG/CombiningKernelAndRamdisk Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
On 14:48 Sat 05 Jul , Stefan Schoenleitner wrote: > > > Robert Schwebel wrote: > > > > If you want to have something which has good community support, check > > what the mainline Linux kernel supports and base your stuff on that. > > > What do you think of this board ? > http://www.olimex.com/dev/sam9-L9260.html If you are looking for a mainline Linux kernel and U-Boot, you could take a look on the AT91SAM9260 or AT91SAM9263 Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
