Re: AMP on an SMP system
On Mon, Aug 05, 2013 at 09:45:23AM +0200, Michael Schnell wrote: > On 08/02/2013 06:16 PM, Jon Sevy wrote: > >You might try the Open Source Automation Development Labs website for > >real-time Linux latency measurements and methodology: > >http://www.osadl.org/ > Thanks for the pointer ! > > On the first glace I see that this might help with legal and similar > issues, but I did not find anything regarding latency, yet. https://www.osadl.org/QA-Farm-Realtime.qa-farm-about.0.html rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: AMP on an SMP system
On Mon, Aug 05, 2013 at 09:25:18AM +0200, Michael Schnell wrote: > > You can't. And you can't, even if you try to run bare-metal software > > on a dedicated core. I can't imagine how for example the cache > > influences between the cores could be determined. > > This would render all efforts for hard realtime embedded Linux > applications useless. You always need to calculate the max latency. You can't calculate the max latency with today's complex processor hardware any more. It's all a matter of system failure probabilities. > Using a dedicated Core will certainly reduce the max latency, but of > course it will not do away with the necessary calculations that take > into account what the other CPUs might do (regarding second level > Cache, cache synchronization, bus scheduling, etc.) I don't think it is possible to get an analytic result for the max latency introduced by other CPUs. What we do today is to run preempt-rt systems, measure them under realistic and extreme load and look at the max latencies. If you design your system in a way that it runs at factor X above this max latency, it should be fine. The advantage of preempt-rt is that you have only one software environment for rt and non-rt. Nevertheless, there always have been settings where you could get rid of all realtime complexity by spending a 1-Euro microcontroller to the BOM. > IMHO, a good compromise is the TI 335x chip that has a single 1 GHz > Cortex A8 and two 300 MHz Cortex A3 cores for a very reasonable price > and and "embedded" specs for temperature range and future chip > availability. AM335x has PRU subprocessors (not ARM architecture). Yes, that can be a solution. Freescale's Vybrid has Cortex-M3 cores. > Right now, I am just investigating viable ways to do things, before > doing a pre-decision for any hardware and starting do dive into that. What kind of application is that? rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: AMP on an SMP system
Hi, On Fri, Aug 02, 2013 at 04:53:50PM +0200, Marco Stornelli wrote: > > In fact I need a way to do very guaranteed low latency. regarding the > > high clock rate (about 1 GHz) modern ARM chips can provide, maybe > > preempt-rt with the cpu affinity might be a decent way to go. Modern hardware has lots of features which makes them basically not deterministic. One recent example: on MX6 (quadcore Cortex-A9), when you run a certain cpuburn tool, the temperature rises up to the maximum allowed value in just a couple of seconds, and then you either have the choice to burn your hardware or to use the tempmon interrupt to throttle down the speed of the cpu. You can imagine what all that means for latencies. So if you want to use a reasonably modern hardware, it is always a matter of "high system probability" of not missing a cycle. > Just to be clear: at the moment there isn't an easy way to dedicate > "completely" a cpu for a task. The last time I tried (some years ago > actually) to use exclusive cpu set, the scheduler didn't do a good > work because it was designed for SMP, not SMP minus some piece. > However you can try and you can report your results. It would be > interesting. Without having done some tests myself, I would expect that the -rt folks have such scenarios. > > The raining questions include > > - how to calculate the maximum latency that can be guaranteed ? (i.e. > > does the Kernel impose any spinlocks and interrupt disables on the would > > be AMP subsystem ?) You can't. And you can't, even if you try to run bare-metal software on a dedicated core. I can't imagine how for example the cache influences between the cores could be determined. > No. You can use full dyn tick for example to disable timer > interrupt, but it has got some pros and cons, especially with very > low latency requirement. > > > - how to assign an interrupt (e.g. a dedicated timer) to the subsystem ? > > Interrupt handler are kernel thread, so you can schedule your kernel > thread on your "normal" cpu. The really great thing with preempt-rt is that it is all Linux and POSIX. No need to invent new things like program starters, inter- process-communication and even inter-processor-communication. > > - Do the interrupts immediately call the ISR of the cpu "under > >affinity" or is some additional latency imposed by the Kernel > > AFAIC, no latency for cpu "under affinity". > > >(and how > >many cpu cycles at max are needed to enter the ISR) ? > > It's difficult to answer to this question because the performance > depends on your system. From my last statistics I saw that with an > rt linux kernel you can stay below 50us for the interrupt latency. Here is an MX53 (single core cortex-a8) in the OSADL testlab: https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot.qa-latencyplot-r0s5.0.html But note that multicore is quite different. I'd suggest that you measure yourself. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: AMP on an SMP system
On Fri, Aug 02, 2013 at 10:33:37AM +0200, Michael Schnell wrote: > Is there a kind of "official" way to set aside one of the available > cores in an SMP system from the Linux OS to do deeply embedded > extremely-low-latency stuff in a kind of single task "main loop" type > environment ? I.e. creating a true coprocessor from an SMP hardware. Before hacking around (which might also lead to interesting solutions), I would start using a kernel with preempt-rt support and play with the cpu affinity: http://lxr.linux.no/#linux+v3.10.4/Documentation/kernel-parameters.txt#L1257 rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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
[ANNOUNCE] memedit-0.8
After 5 years of development, there is a new memedit release out :-) http://www.pengutronix.de/software/memedit/index_en.html Memedit is a small tool that can be used to map & access physical memory on embedded devices. The new feature is that we have memory fill support now. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: Super Fast Boot of Embedded Linux: 300 ms from boot loader to shell
On Thu, Apr 14, 2011 at 09:43:35AM +0200, Matthieu CASTET wrote: > Not to say such case are not interesting : loading a linux kernel with > only a serial driver, a ramdisk and a shell as init doesn't reflect > reality. > > In real product what you want if fast user interaction (sound, > mounting big filesystem with user data, lcd display, ...) Well, it depends on the application. In the automotive box I've shown the barebox based boot optimizations for in my ELC-E talk, the task is to get CAN communication running in < 200 ms. For that kind of application it's useful to be in userspace as fast as possible, just in order to have one socket-can application running, and everything else comes later. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: Embedded Linux Boot Time Poll
Hello Andrew, On Fri, Oct 22, 2010 at 12:20:50AM +0100, Andrew Murray wrote: > I'm performing some research [for a CELF presentation] into reducing > boot time on embedded systems and would like to see if the embedded > community agree with the following statement as to why Linux > [arguably] takes so long in the first place for an unoptimised system: > > "Linux is general purpose, convenient and flexible. As it's general > purpose it's likely to contain un-required functionality which results > in more initialisation and a larger image size. As it's convenient and > flexible it will spent time discovering devices and verifying their > existence." > > Do you largely agree or disagree? Also do you believe that boot time > isn't the highest priority when it comes to improving the kernel? I second what the others have already written. With a resonably tuned system it is possible to gain boot times of < 0.5 s into the Linux userspace on a 532 MHz MX35 (ARM1136). What highly matters if the use case, which in turn influences what can be done to decrease the boot time. - If a distribution is tuned to "run everywhere", it has to do a lot of probing, which needs time (i.e. a general purpose distribution on an ARM or PowerPC). In turn, you can easily install almost everything on such a system - If a system can be optimized for a special scenario (i.e. a machine operator terminal), you can configure away almost all unrequired functionality. In turn, it may be difficult to install random software parts on such a system. It's more a matter of paradigms. I assume we'll have nice boot time discussons at ELC-E, I also have a talk there concering this topic :-) rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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
[ANNOUNCE] barebox-2009.12.0 has been released
dd a i.MX IPU framebuffer driver mx35 3stack display support Luca Ceresoli (1): Turn on CONFIG_CMD_MEMORY in Beagle Board defconfig. Marc Kleine-Budde (26): fec_imx: remove trailing whitespace clock.h: uses uint?_t types, so include types.h nand: print size parameter as unsinged not as signed nand: ground dev_add_bb_dev if nand is disabled spi: dev->id is an int, not a string, fix debug output speed-imx35: the gptclk is connected to the ipgclk speed-imx35: add function imx_get_i2cclk imx-regs: define IMX_FEC_BASE mx25-3stack, pcm043: use IMX_FEC_BASE define imx35-regs: add base address for I2C1 imx35-regs: add CGR1 helper values i2c: new framework i2c-imx: ported to u-boot-v2 mc13892: driver added mc9sdz60: driver added clock.h: use types.h not linux/types.h clock.c: use USECOND and MSECOND i.MX35 3stack: several enhancements i2c-imx: print errors with dev_err i2c-imx: fix clear IFF race condition i2c-imx: fix low bitrate problem i2c-imx: i2c_imx_xfer return with err if sub-transfer isn't successfull arm/Makefile: don't set ABI unconditionally to "apcs-gnu" Cleanup some more collateral damage from renaming arm/lib: add eabi names of helper functions arm/lib: add missing abi helper functions __aeabi_idivmod, __aeabi_uidivmod Peter Korsgaard (4): image.h: amd64 support sandbox: common: fix device names for environment files (-e) cramfs: probe(): fix cdev lookup Documentation: update reference to sandbox environment Robert P. J. Day (9): ARM: Correct Kconfig typo, "optimzed" -> "optimized". NAND: Free asprintf()-allocated space upon mtd device deletion. commands: correct "CONFIG_SIMPLE_PARSER" to "CONFIG_SHELL_SIMPLE". scripts: Delete non-barebox content from scripts/. commands: Remove reference to non-existent CONFIG_CMD_I2C. Remove/adjust erroneous references to CONFIG_MODULE. MTD: Correct typo in preprocessor directive. Remove obsolete comment referring to CFG_CMD_JFFS2. Remove PPC support for IDE. Robert Schwebel (2): README: rewrite some u-boot leftovers README: add release rules Sanjeev Premi (2): omap3evm: Add basic support for the board omap3evm: Minimal default configuration Sascha Hauer (225): return is not a function arm: implement optimized string functions imx_nand: Skip bbt scan during initialization armlinux: remove unused atags armlinux.c: refactor arm: make 'bootz' configurable arm: Add bootu command Add MMU support fec imx27: Add MMU support pcm038: Add MMU support i.MX: Do not dump clocks on startup. imx nand: Make use of optimized string functions ehci: Restore state after td timeout i.MX: Use more accurate decode pll function from kernel usb: when unregistering usb devices, remove them from device list use _stext instead of TEXT_BASE imx serial: add mx25 support add iomux definitions for mx25 Add MX25 support nand_base: We have to ignore the -EUCLEAN error add Freescale MX25 3stack board support add mx25 3ds defconfig MX25/MX35 Nand support imx27: Add usb defines pca100: Add MMU support pca100: Add USB host support usb ehci driver: Get rid of echi_alloc/free usb ehci driver: Add MMU support usb: remove unnecessary code usb: remove unused fields from struct usb_device pcm038: Add USB support ethact command: If called without arguments print current eth device nand bb: fix check when erasing a bb device nand bb: fix removal of bb devices devfs: add open counter ls: beautify output make copy_file() globally available add xstrdup function devfs: fix return value for lseek in partitions mx25: implement clko command mx25: remove duplicate function, fix perclk values console: make locally used function static hush: Only run list if it's not empty hush: pass return code from exit command rename dma macros console: partly revert 84688dfdb4aecc8296b4fef9bc657335d7b9ade5 Add USB device support register env as env0 and not as env readline: Allow only ascii and printable characters fs: replace broken dev_protect with protect_file function boards: use recently introduced protect_file function imx: replace imx specific gpio functions with generic ones imx spi: Use gpio as chip selects mc13783: fix spi mode, remove now unneeded double read nand_imx_v2: use xzalloc for data buffers nand_imx_v2: make nand_boot_test command more flexible i.MX introduce cpu_is_*() macros nand_imx_v2: abstract i.MX25 specific stuff p
Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
On Wed, Dec 23, 2009 at 09:29:22AM +, Andy Green wrote: > > If you don't step into for example toolchain problems or other crazy > > things... > > Again this is buildroot thinking. The distro provides both the native > and cross toolchains for you. You're going to want to use the same > distro as you normally use on your box so the cross toolchain installs > as a package there. > > If all that's left is the risk of "crazy things" happening well that's > a risk whatever you do or even if you do nothing :-) What I mean is that in the past we had more than once the case that we've found showstopper bugs in upstream gcc, binutils etc. (ARM has much less coverage than x86). It was never a problem in the project, because we actually have been able to port test cases to the latest gcc, reproduc, report to upstream, get it fixed, port it back. That at least implies that you *are* able to rebuild everything (which is possible in both ways, of course). > The only thing I know of that matches "outside the kernel" requirement > is the machine ID that's passed in on ATAG. I agree it's generally > good to have a single build that's multipurpose. Machine ID is a good concept, but doesn't work on everything. What's the machine on a system that consists of a cpu module and a baseboard? Things move into the oftree direction, and I think bootloaders have to deal with that, or there has to be a possibility that an early kernel stage deals with the oftree. But that just moves the hackery-code from the bootloader into the kernel, which is no gain. > On iMX you have to go read IIM to get device info but actually that's > not hard. ... as long as the hardware guys don't decide in their great wisdom to change the meaning of some bits from chip to chip ... > But that device ID will itself alone tell you the on-SoC peripherals > since there's an ID per die; it makes no difference if this expanded > SoC oftree data itself lives in the kernel then. The non-SoC stuff > can just be probed. Off-board devices behind SPI, I2C and chip select busses cannot be probed. You are observing a subset of the embedded universe, and you are right if you limit to it. Bootloaders like barebox or u-boot provide a concept for *all* use cases. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
On Wed, Dec 23, 2009 at 08:38:08AM +, Andy Green wrote: > I don't know or care when I get the binary packages from a repo where > they're already built. The whole point of a distro solution is someone > did all the work for you. You're only thinking about mass rebuild > yourself because it's the buildroot mindset, that whole task > disappears with a distro basis. If you don't step into for example toolchain problems or other crazy things... > You can emulate "issue 6 monthly rootfs tarball updates" by just > updating the stable package repo at long intervals with well-tested > packagesets. At the same time you can offer other repos with newer > features earlier, get changed packages tested easier, confirm > patchlevel on test systems, etc. Yes, that's a valuable option. > I take your point but actually there's no reason the *bootloader* > needs that when the bootloader is focussed solely on booting Linux. > *Linux* might want an equipment list from the board, but then > typically you would build all the drivers and they can simply probe > and fail if its not there on the board. The oftree is currently provided by the bootloader, and much of what it contains is unprobable peripherals, i.e. the IP cores in the SoC cpus. For example for i.MX (which we happen to maintain in the mainline), there is a strong aim for having one kernel that runs on as many devices as possible. If you want to do this and if you can't probe significant parts of the hardware, you need an instance outside of the kernel who tells you what's actually there. > I'm not sure I managed to give the flavour of a bunch of hardware guys > half a world away rotating in and out on Military service. Even > patches internally aren't happening, Mainline isn't an answer. Well, there are many projects out there which are not so secret that one cannot expose the kernel drivers. And even if they are, it is possible to establish a peer-review culture inside of a corporation. But you won't get the full power of community review. That's the trade off one has to accept for having secrets :-) But quality is generally a big issue. > > > bus driver back into the bootloader. But actually, normal > > > customers don't care about 200ms on boot either way. They can get > > > the thing to market quicker and so cheaper and more reliably > > > without that stuff in the bootloader. > > > > That's a matter of the definition of "normal customers" :-) > > What I mean by it is for geeks like us, it's interesting to see how > fast it will go. The actual customer cannot tell 200ms by eye he will > accept it if it's not passing his threshold of being "too slow". But > he will like getting it shipping earlier because the bootloader is > almost invisible in dev effort and in management of production. We have customers who care about "splash in 0.5 s" vs. "shell runs after 3 s, then qt starts". People may be used to that kind of noticable boot time in the phone business, but in the industry (where embedded Linux boxes are even more "devices" than computers) they often are not. Do you remember the times when we had analog TV? We could zap through 5 channels in under 3 seconds. *That's* performance :-) My sattelite receiver needs about 10 seconds to boot. Sometimes it feels like innovation goes backwards. Cheers, rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
Hi Andi, On Tue, Dec 22, 2009 at 10:23:37PM +, Andy Green wrote: > Fedora provides a whole solution there, with the restriction it's > designed for native build, not cross. That's probably also a matter of taste. I still find it a feature to be able to cross compile the systems - we can still recompile whole systems consistently in just a few (ten) minutes, i.e. in order to change a central switch (like softfloat vs. hardfloat, use another toolchain etc). Out of interest, how long does it take to recompile Fedora on for example MX31? > Packages only help any QA effort. You don't have to release every > package build to your stable repo, a staged development / testing / > stable repo scheme is simple. For let's say a telematics box it's almost impossible to test packet combinations. All you can do is decide for "update application" and "update platform". If you got your software updates via SMS, it shouldn't go wrong because of an untested packet combination :-) > Right. Fedora is different though, there are no cross-built packages > (although they do provide cross compilers, I use them for kernel and > Qi builds) and if storage is sufficient, there's no need to strip > anything out. Just nobble init. Hmm, I'm still not convinced. But as I don't have any data, I'll keep quiet :-) I think a central question is if you want to optimize things like * early boot splash * footprint > Well for my uses of it I have been able to specify that we should have > versioning GPIOs on the boards. It's a good idea anyway. Hardware description is still one of the unsolved problems out there. It works good if you have just a few variants. We often have for example 5-10 assembly options on a cpu module, plus several on the base board, all not in-system detectable. We tried several variants to describe the hardware in some config block, we tried to have oftree sniplets in the hardware, but none of the options did really work well. In the end, you need the schematics in machine readable form... When oftree comes into the ARM world, we need a maximum-style bootloader which can provide oftrees. > > > What it led to was private bootloader trees that did not track the > > > main one, filled with perverted bit-twiddling code that was not > > > understood by anyone except the guy who wrote it, and that guy > > > left a while back as did the guy after him. > > > > That's solvable by working on mainline integration. You'll get this > > problem with Linux as well, if people are not on a mainline > > strategy. No tool can change that. > > It's nothing to do with mainline, just intra-company communication and > management failure. My experience is that mainline exposure of that perverted bit-twiddling code and ideas helps finding sane solutions, because someone will allways ask the right questions :-) > > Unfortunately, often people want to boot as fast as possible, which > > requires optimization in that area as well. We recently had a board > > which refused to boot without the PMIC having switched on some > > voltages which are default-off. > > If your device is able to run from USB power, there's the issue that > you are limited to 100mA before enumeration takes place. So without a > USB stack, you have to trade speed for power anyway. My argument is that there are all these different requirements out there: your use cases, mine, others. What we want to do with barebox is turning u-boot into something that can fulfill all of these requirements, not only parts of it. You don't need a network driver in your bootloader? Just configure it out and don't look at the code. But somebody else may care, and he has a sane design to put his driver into. The maximum paradigm works as good as the minimum does. > > My fear is that quite often one starts with "oh, this problem is > > simple, let's design simple". Then things move on and you notice > > that you need to work on SPI, I2C, you need ext2, jffs2, ubifs, > > later maybe btrfs, then SD support or USB. In the end, the problem > > turns out to be complicated. > > You're right to fear it because you are too willing to re-introduce > the bloat into your bootloader. For example you mention earlier that > "Unfortunately, often people want to boot as fast as possible" and > that is the rationale for re-introducing PMU management and the serial > bus driver back into the bootloader. But actually, normal customers > don't care about 200ms on boot either way. They can get the thing to > market quicker and so cheaper and more reliably without that stuff in > the bootloader. That's a matter of the definition of "normal customers" :-) > No offence but you are basically describing U-Boot there, mini Linux, > scripting, hacks. Surely like U-Boot dreams of growing up into Linux, > you will find your project dreaming of growing up into U-Boot. Well, we think we have found a good design for reducing the hack factor significantly. While I'm still convinced that, for our projects, we have
Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
Hi Andy, [is this the right set of lists to discuss these issues? It's not directly CELF related, but I don't know a better place for general project independend bootloader discussions] On Tue, Dec 22, 2009 at 08:22:27AM +, Andy Green wrote: > DFU is a "special update mechanism" which I believe is a bad idea. For dedicated embedded system in the non-phone league, with small root filesystems, it works pretty well. > I know a lot of people are still putting out full rootfs images as > updates, and for some platforms that are too resource-constrained > that's all people can do. Ah, ok, we don't do that. > But for modern devices like ARM11+ and the kind of board they > typically find themselves on with a network connection, these are > fundamentally at the level of PC from a few years ago. Linux PCs then > and now use packaged update systems to manage the software on the > device. And they package both the kernel and the bootloader and track > and update it like any other package, apply packagesets as > transactions, etc. The correct approach I believe is to unify the > bootloader (and kernel) update path with the rest of the system, all > done from Linux alone. > > (Personally I used Fedora ARM port and RPM, but any distro and > packagesystem like Debian workable on ARM would be fine). Until now, we are using the "build it yourself" approach with ptxdist, basically because of these reasons: - If something goes wrong, we want to be able to fix it, which means that we must be able to recompile everything. Having the source is no value by itself, if you are not able to build it. - Root filesystems are small; a complete rootfs for a typical industrial application with Linux, glibc, dbus and qt is about 20...30 MiB. - People don't change software that often, and if they do, it has to be made sure that it is absolutely well tested. Nobody wants to reboot their deeply embedded machine controller at the other end of the world if somehting goes wrong. We usually don't have an administrator who can interoperate if something goes wrong. - Customizability. We recently tried Debian on the Neo, and it is an absolute mess. About 2.5 minutes of boot time, a lot of flicker and almost no reactivity of the system. So for us, the question remains how to customize standard distributions in a reproducable way. So at least at the moment, I prefer ptxdist over a customized debian. But in general, I respect the argument why people want to use standard distributions (I know the pain to fix all the cross compiling issues). I just don't think that today's distributions are there yet. Most embedded systems I've seen so far which follow the strip-down-standard-distro pattern have been unreproducable for anyone but the original developer. > So we were actually unable to migrate to hard ECC in Linux, which is > an insane outcome of a broken system. > > In contrast if your chip supports it (iMX31 and s3c6410 do and Qi > works with those) having your bootloader on some sectors of SD card is > wonderfully simple and easy to dd in on a postinstall scriptlet of > your bootloader package. Agreed. > > In general, I like in-system techniques much better than card > > juggeling, because it fits better into automated environments like > > our RemoteLab, which does our automatic nightly tests. But that's > > surely a matter of the use case you have. > > Agreed. > > But consider this: if your bootloader is on SD, and your bootloader > completely rejects to hold private state on the board (other than > onetime individualization, eg MAC address), something awesome happens > when you pop your SD card and put it in another board, it comes up > like the previous board did, no ifs or buts. > > You can imagine the effect that has on production / test "virgin" > board bringup. When you have seen this, you do not want to return to > raw onboard NAND. In general, I agree with you here (although I think the MAC address should be glued to the hardware and not change if you change SD cards -> people will then copy it and you have the same MAC address twice). However, I think it's more developer friendly to have that "no changable state" as a policy than a design decision: during development, we quite often change for example the kernel command line (adding quiet or debug switches, boot from net/disk...). For delivery, we just make barebox + it's scripting environment one image and change that to r/o, if necessary. So you can get best of both worlds. > > In barebox, we use Kconfig to configure things away; so removing > > unnecessary features is just a matter of 'make menuconfig'. > > That is good, but what I am suggesting is that > > - these things are definitively unnecessary, ie, they deserve > permanent deselection > > - the config system leads to bootloader-binary-per-variant Hell For us, the bootloader is not only something which is delivered with the product - that's one use case. But there is also quite a long time
Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
Andy, On Mon, Dec 21, 2009 at 10:38:31PM +, Andy Green wrote: > About tapping into the wisdom of the U-Boot community, most of their > changes were GTAxx-specific. For example I don't know any other Linux > device than GTA02 with a Glamo in it, there is a lot of code I ported > from Linux for that bloating their tree. With closed docs, that would > be completely useless for upstream. Hmm, there have been interesting items in the openmoko trees. For barebox, we took the DFU support, which was done in a device specific way, cleaned that up and made a generic command out of it: dfu /dev/self0(bootloader)sr,/dev/nand0.root.bb(root) You can specify the slots on the command line, not hardcoded. Whereas we reworked the interfaces, the core code was pretty interesting. So I think some items it would have been worth to be pushed into u-boot at the time it was written. > Bearing in mind they could only update by DFU and with GTA01, there > was no bootloader recovery mechanism if it failed, Our DFU scenario goes like "press a button while booting goes into DFU mode", so you can re-flash as often as you like. However, our use cases are probably different than yours (deeply embedded systems, which often don't even have removable stuff like SD or USB sticks). In general, I like in-system techniques much better than card juggeling, because it fits better into automated environments like our RemoteLab, which does our automatic nightly tests. But that's surely a matter of the use case you have. > The main lessons I took from that was the dollar and time value of > removing the "unnecessary features" in U-Boot and especially the > Openmoko tree of it: In barebox, we use Kconfig to configure things away; so removing unnecessary features is just a matter of 'make menuconfig'. > - video drivers I see video drivers in the bootloader as an optimization topic: If you can effort to get your splash 3 s after power-on, you should leave video drivers out of the boot loader and do it all in the kernel. Our competition in industry projects is often the old 2-lines-alpha displays, which are "instant on" after you hit the power switch. If this is required, I don't see a way to achieve that with kernel-only at the moment. > - shells Especially during development, we often see that the hardware people really like having a very limited shell with hardware bit banging access in barebox. In a phase where you port Linux to a device, it gives you something that works while Linux is not ready yet. And in barebox, you have full scripting capabilities, so hardware people can even use that for certain qualification scripts. > - environments That was one of our design goals in barebox as well: get rid of the scripting in the environment, as it was done in u-boot. > - special update mechanisms What do you mean with "special"? > - raw NAND at all > - duplicating the OS in there If you want to boot from NAND-only devices, how would you do that without NAND drivers? > - private nonvolatile state ? > - PMU management when we are already able to run Several CPUs need PMU support early in the boot stage, because they come up in slow-clock mode. So you either boot slow until the kernel is up far enough (but then the whole kernel loading is slow), or you need access to the PMU from the bootloader. In barebox, our design is that we have frameworks for i2c+spi to access a PMU, but if you don't need that, you can configure it away. The idea is that *if* you actually need it, then better have a good design for it. > - per board variant bootloader image (ie, GTA02 v3 can only run a > special GTA02 v3 binary of U-Boot that can't run on anything else; > Qi has a per CPU binary that supports all variants) I don't know the GTA02 hardware, but it is often a problem to actually detect a certain CPU or board variant on runtime. But if that's possible, I don't see a reason why you can't make a single image. We had one strange case with an MPC5200 where the bootup bus configuration was so complicated that it was a major issue and we decided for different bootloaders, but in general it should be possible. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: [ANNOUNCE] CELF open project proposal
On Fri, Dec 04, 2009 at 02:29:12PM +1100, Aras Vaichas wrote: > > In barebox (aka u-boot-v2) we have USB DFU support, in a very flexible > > way. Would that fit your needs? > > That would probably be better than TFTP over ethernet. A USB DFU > upgrade would only require the microcontroller to be functioning for > the upgrade to work and it doesn't require TCP/IP stack or ethernet > chip drivers. Yup. Barebox has Kconfig as it's configuration system, so you can make components y/n/m. It follows the same module mechanism as the kernel, so you can insmod drivers if you need them. > I maintain a family of devices which can be built with or without > ethernet. Currently we attach an ethernet daughterboard to the device > to bootstrap it, and for development, but remove it for commercial > use. Sounds like a usecase for insmod :-) rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: [ANNOUNCE] CELF open project proposal
On Thu, Dec 03, 2009 at 10:38:07PM +0900, Kyungmin Park wrote: > How about the TFTP over USB? It's required feature for no ethernet devices In barebox (aka u-boot-v2) we have USB DFU support, in a very flexible way. Would that fit your needs? > I wish some filesystem to share between u-boot and kernel. Of course > ext2 or fat is possbile. but current u-boot implementation depends on > block device or NOR device. not for NAND/OneNAND devices. That would indeed be interesting. > Finally very very small jpeg or png library for u-boot (under 30KiB). What's your use case for that, a splash screen? rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: [ANNOUNCE] CELF open project proposal
Hi David, On Wed, Dec 02, 2009 at 09:59:50PM +, David Woodhouse wrote: > On Wed, 2009-12-02 at 13:46 -0800, Tim Bird wrote: > > It applies to anything in the "embedded Linux" ecosystem. This > > would very much include open source boot loaders like U-Boot. > > And coreboot. > > The world needs more coreboot. Did you have a look at u-boot-v2 (which is just in the process of being renamed to barebox)? We have it running on all kind of architectures (even x86 is working here recently, but the patches are not ready for mainline yet), and it feels much more linuxish than coreboot. http://www.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations?action=AttachFile&do=view&target=Hauer-U_BootV2.pdf Robert -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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
[ANNOUNCE] New mailing list for u-boot-v2
Hi, After Sascha Hauer's talk [1] about u-boot-v2 [2] at ELC-E [3] there was an increasing demand for a separate mailing list for this new boot- loader. So this is just a short note that, in the meantime, such a list has been created on infradead [4]. Robert PS: Many thanks to the organizing crew - it was really a great pleasure to meet so many of you guys in real life! :-) [1] http://www.pengutronix.de/events/20091015-ELC-Europe/PRE-20091017-1-OSELAS.Training-U-Boot-V2.pdf [2] http://www.pengutronix.de/software/u-boot/v2/index_en.html [3] http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations [4] http://lists.infradead.org/mailman/listinfo/u-boot-v2 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: New fast(?)-boot results on ARM
On Tue, Aug 18, 2009 at 12:48:50PM +0200, Alex Riesen wrote: > But many of the problems you described and suggested solutions > point at userspace, right? (like pre-defined static /dev, mdev script, > or using of specially designed rootfs) Yes, right. But even there, mdev is more in the "embedded special" league than udev, for example, and highly specialized read-only root filesystems as well. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: New fast(?)-boot results on ARM
On Tue, Aug 18, 2009 at 12:34:52PM +0200, Alex Riesen wrote: > On Tue, Aug 18, 2009 at 12:21, Robert Schwebel > wrote: > > - In general we want to have our systems close to what the mainline > > does; Automation & Embedded is only a small market, and anything > > which is *not* specific to these markets but mainline is good. > > BTW, what is your mainline (or it looks like you mean "upstream")? unpatched kernel.org rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: New fast(?)-boot results on ARM
Marco, On Tue, Aug 18, 2009 at 12:06:48PM +0200, Marco Stornelli wrote: > Yeah, I agree, do you really need udevd, device file creation at every > start-up in /dev? Usually static devices nodes and mdev for hotplug are > enough or at least you could use a simple script to create only once > time the devices file (mdev -s). About the fs, do you really need a > rootfs with ubifs? I mean, you could "split" your fs. You could use a > read-only fs (SquashFS for example) for your root-fs, ubifs for > permanent storage data (mounted under /data for example) and a ram fs > for volatile data. Well, we try to find out what is possible with a fast booting Linux system which *still* is as "vanilla" as possible. All the "boot-in-one-second" systems out there are highly squeezed, which is surely good if you have a scenario with high production volumes. You can do the optimization in the last steps then and it doesn't really matter how much time you spend with testing to come from a system that works for a developer to a production system. For most of our use cases here at Pengutronix, we see that: - Customers want in-system upgradability on a per-packet base; so the flash filesystems should be normally r/o, but may be remounted r/w. - Development systems should be close to production systems, in order to be able to have more "early testing"; so things like printk-ripout or special non-mainline patches/tweaks should be avoided as far as possible. - In general we want to have our systems close to what the mainline does; Automation & Embedded is only a small market, and anything which is *not* specific to these markets but mainline is good. So let's see what we'll reach while trying what people have suggested. Thanks, rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: New fast(?)-boot results on ARM
On Fri, Aug 14, 2009 at 11:01:58PM +0200, Linus Walleij wrote: > >> > That's factor 70 away from the 110 ms boot time Tim has talked about > >> > some days ago (and he measured on an ARM cpu which had almost half > >> > the speed of this one), and I'm wondering what we can do to improve > >> > the boot time. > >> > >> 2.4s in uncompression? That seems like an obvious target for > >> improvement. > > > > Indeed, we'll check that. > > We got rid of uncompression on a flash-based system vastly improving > boot time. The reason is that compressed kernels are faster only when > the throughput to the persistent storage is lower than the decompression > throughput, and on typical embedded systems with DMA the throughput to > memory outperforms the CPU-based decompression. > > Of course it depends on a lot of stuff like performance of flash controller, > kernel storage filesystem performance, DMA controller performance, > cache architecture etc so it's individual per-system. We have also done that on NOR based systems, but I'm not sure if it will work out for NAND as well. Thanks, rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: New fast(?)-boot results on ARM
On Fri, Aug 14, 2009 at 10:04:57PM +0200, Denys Vlasenko wrote: > > r...@thebe:~$ microcom | ptx_ts "U-Boot 2.0.0-rc9" > > [ 2.395740] < 2.395740> > > [ 2.395860] < 0.000120> > > [ 0.11] < 0.11> U-Boot 2.0.0-rc9 (Aug 5 2009 - 10:05:58) > > [ 0.59] < 0.48> > > [ 0.003823] < 0.003764> Board: Phytec phyCORE-i.MX27 > > [ 0.010753] < 0.006930> cfi_probe: cfi_flash base: 0xc000 size: > > 0x0200 > > [ 0.018711] < 0.007958> NAND device: Manufacturer ID: 0x20, Chip ID: 0x36 > > (ST Micro NAND 64MiB 1,8V 8-bit) > > [ 0.026592] < 0.007881> im...@imxfb0: i.MX Framebuffer driver > > [ 0.178655] < 0.152063> dev_protect: currently broken > > [ 0.178736] < 0.81> Using environment in NOR Flash > > [ 0.182577] < 0.003841> initialising PLLs > > [ 0.367142] < 0.184565> Malloc space: 0xa3f0 -> 0xa7f0 (size 64 > > MB) > > [ 0.370568] < 0.003426> Stack space : 0xa3ef8000 -> 0xa3f0 (size 32 > > kB) > > [ 0.445993] < 0.075425> running /env/bin/init... > > [ 0.870592] < 0.424599> > > [ 0.874559] < 0.003967> Hit any key to stop autoboot: 0 > > boot loader is not fast. considering its simple task, it can be made > faster. Yup, will check. Almost 1 s seems really long. > > [ 1.326621] < 0.452062> loaded zImage from /dev/nand0.kernel.bb with size > > 1679656 > > [ 2.009996] < 0.683375> Uncompressing > > Linux... > > done, booting the kernel. > > [ 2.416999] < 0.407003> Linux version 2.6.31-rc4-g056f82f-dirty > > (s...@octopus) (gcc version 4.3.2 (OSELAS.Toolchain-1.99.3) ) #1 PREEMPT > > Thu Aug 6 08:37:19 CEST 2009 > > Other people already commented on this (kernel is too big) Not sure (the kernel is already customized for the board), but I'll take a look again. > > [ 2.418729] < 0.001730> CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), > > cr=00053177 > > [ 2.423081] < 0.004352> CPU: VIVT data cache, VIVT instruction cache > > [ 2.426592] < 0.003511> Machine: phyCORE-i.MX27 > ... > > [ 2.742628] < 0.016050> 0x0036-0x0400 : "root" > > [ 3.058610] < 0.315982> UBI: attaching mtd7 to ubi0 > > [ 3.062878] < 0.004268> UBI: physical eraseblock size: 16384 bytes (16 > > KiB) > > [ 3.070601] < 0.007723> UBI: logical eraseblock size: 15360 bytes > > [ 3.070665] < 0.64> UBI: smallest flash I/O unit: 512 > > [ 3.078564] < 0.007899> UBI: VID header offset: 512 (aligned 512) > > [ 3.078609] < 0.45> UBI: data offset: 1024 > > [ 5.006609] < 1.928000> UBI: attached mtd7 to ubi0 > > [ 5.013157] < 0.006548> UBI: MTD device name: "root" > > As others commented, ubi looks slow and you probably need to find out why. So it seems like our UBS is much slower than usual? > > [ 5.014566] < 0.001409> UBI: MTD device size: 60 MiB > > [ 5.018660] < 0.004094> UBI: number of good PEBs: 3880 > > [ 5.022585] < 0.003925> UBI: number of bad PEBs: 0 > > [ 5.026797] < 0.004212> UBI: max. allowed volumes: 89 > > [ 5.026849] < 0.52> UBI: wear-leveling threshold: 4096 > > [ 5.030779] < 0.003930> UBI: number of internal volumes: 1 > > [ 5.034583] < 0.003804> UBI: number of user volumes: 1 > > [ 5.046572] < 0.011989> UBI: available PEBs: 0 > > [ 5.046622] < 0.50> UBI: total number of reserved PEBs: 3880 > > [ 5.046657] < 0.35> UBI: number of PEBs reserved for bad PEB > > handling: 38 > > [ 5.050606] < 0.003949> UBI: max/mean erase counter: 2/0 > > [ 5.050668] < 0.62> UBI: image sequence number: 0 > > [ 5.058619] < 0.007951> UBI: background thread "ubi_bgt0d" started, PID > > 215 > > [ 5.062620] < 0.004001> oprofile: using timer interrupt. > > [ 5.070584] < 0.007964> TCP cubic registered > > [ 5.070637] < 0.53> NET: Registered protocol family 17 > > [ 5.074624] < 0.003987> RPC: Registered udp transport module. > > [ 5.082616] < 0.007992> RPC: Registered tcp transport module. > > [ 5.605159] < 0.522543> eth0: config: auto-negotiation on, 100FDX, > > 100HDX, 10FDX, 10HDX. > > [ 6.602621] < 0.997462> IP-Config: Complete: > > [ 6.606638] < 0.004017> device=eth0, addr=192.168.23.197, > > mask=255.255.0.0, gw=192.168.23.2, > > [ 6.614588] < 0.007950> host=192.168.23.197, domain=, > > nis-domain=(none), > > [ 6.618652] < 0.004064> bootserver=192.168.23.2, > > rootserver=192.168.23.2, rootpath= > > Well, this ~1 second is not really kernel's fault, it's DHCP delay. > But, do you need to do it at this moment? > You do not seem to be using networking filesystems. > You can run DHCP client in userspace. The board has ip autoconfig configured in, because we also use tftp/nfs boot for development. But it had been disabled on the commandline: ip=192.168.23.197:192.168.23.2:192.168.23.2:255.255.0.0::: That shouldn't do dhcp, right? > So, about 4 seconds for
Re: New fast(?)-boot results on ARM
On Fri, Aug 14, 2009 at 07:46:51PM +0100, Jamie Lokier wrote: > Zan Lynx wrote: > > Or maybe its cheap and slow flash. In that case I think your only > > hope is to make all the code as small as possible and/or find a > > different flash filesystem that does not have to read so much of the > > device to mount. Perhaps use a read-only compressed filesystem for > > the system binaries and reflash it for software upgrades. Only init > > and mount the writable flash for user-storable data well after > > system boot has finished. > > Fwiw, logfs claims to mount quickly, but I haven't heard much about it > in recent months and http://logfs.org/logfs/ implies it's not really > stable yet. But maybe if you're working on a prototype that doesn't > matter so much. Is logfs ready for production in the meantime? Last time I checked it was still more or less Jörn's pet project and ubifs seemed much more mature. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: New fast(?)-boot results on ARM
Zan, On Fri, Aug 14, 2009 at 12:19:48PM -0600, Zan Lynx wrote: > > That's factor 70 away from the 110 ms boot time Tim has talked about > > some days ago (and he measured on an ARM cpu which had almost half > > the speed of this one), and I'm wondering what we can do to improve > > the boot time. > > 2.4s in uncompression? That seems like an obvious target for > improvement. Indeed, we'll check that. However, I have a little bit the impression that most systems which are hyped as "fast boot" out there are optimized so aggressively that they are not really usable in real life applications any more. So we try to configure the systems in a "realistic" way. I know that we won't get the last milliseconds that way - but I'd like to find out how far we can go. > Your kernel seems awfully large. 3104K code? You should definitely find > out what is making it that big and cut out everything you do not need. Definitely, will audit again. > You might even try some of the embedded system scripts that rip out > all the printk strings. Hmm, that's definitely in the "last-minute-before-product" category. > If you get the kernel size way down then use a uncompressed kernel and > it should boot a lot faster if the bottleneck is CPU speed. I'll try that. > However, it is probably IO speed. There could be something really wrong > and slow with your MTD. Does it DMA or is it doing something crazy like > using the CPU to read a byte at a time? Will check. > Or maybe its cheap and slow flash. In that case I think your only hope > is to make all the code as small as possible and/or find a different > flash filesystem that does not have to read so much of the device to > mount. Perhaps use a read-only compressed filesystem for the system > binaries and reflash it for software upgrades. Only init and mount the > writable flash for user-storable data well after system boot has > finished. That would be also a last-minute change, but surely worth to be evaluated. We recently changed from jffs2 to ubifs and hoped to gain speed during that step. Thanks for your feedback! rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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
New fast(?)-boot results on ARM
Hi, On Thu, Aug 13, 2009 at 05:33:26PM +0200, Robert Schwebel wrote: > On Thu, Aug 13, 2009 at 08:28:26AM -0700, Arjan van de Ven wrote: > > > That's bad :-) So there is no room for improvement any more in our > > > ARM boot sequences ... > > > > on x86 we're doing pretty well ;-) > > On i.MX27 (400 MHz ARM926EJ-S) we currently need 7 s, measured from > power-on through the kernel up to "starting init". This is with > > - no delay in u-boot-v2 > - rootfs on NAND (UBIFS) > - quiet > - precalculated loops-per-jiffy > - zImage kernel instead of uImage Here's a little video of our demo system booting: http://www.youtube.com/watch?v=xDbUnNsj0cI As you can see there, it needs about 15 s from the release of the reset button up to the moment where the application shows it's Qt 4.5.2 based GUI (which is when we fade over from the initial framebuffer to the final one, in order to hide the qt application startup noise). And below is the boot log (after turning "quiet" off again). The numbers are the timestamp and the delta to the last timestamp, measured on the controlling PC by looking at the serial console output. The ptx_ts script starts when the regexp was found, so the numbers start basically in the moment when u-boot-v2 has initialized the system up to the point where we can see something. Result: - 2.4 s up from u-boot to the end of "Uncompressing Linux" - 300 ms until ubifs initialization starts - 3.7 s for ubifs, until "mounted root" So we basically have 7 s for the kernel. The rest is userspace, which hasn't seen much optimization yet, other than trying to start the GUI application as early as possible, while doing all other init stuff in parallel. Adding "quiet" brings us another 300 ms. That's factor 70 away from the 110 ms boot time Tim has talked about some days ago (and he measured on an ARM cpu which had almost half the speed of this one), and I'm wondering what we can do to improve the boot time. Robert r...@thebe:~$ microcom | ptx_ts "U-Boot 2.0.0-rc9" [ 2.395740] < 2.395740> [ 2.395860] < 0.000120> [ 0.11] < 0.11> U-Boot 2.0.0-rc9 (Aug 5 2009 - 10:05:58) [ 0.59] < 0.48> [ 0.003823] < 0.003764> Board: Phytec phyCORE-i.MX27 [ 0.010753] < 0.006930> cfi_probe: cfi_flash base: 0xc000 size: 0x0200 [ 0.018711] < 0.007958> NAND device: Manufacturer ID: 0x20, Chip ID: 0x36 (ST Micro NAND 64MiB 1,8V 8-bit) [ 0.026592] < 0.007881> im...@imxfb0: i.MX Framebuffer driver [ 0.178655] < 0.152063> dev_protect: currently broken [ 0.178736] < 0.81> Using environment in NOR Flash [ 0.182577] < 0.003841> initialising PLLs [ 0.367142] < 0.184565> Malloc space: 0xa3f0 -> 0xa7f0 (size 64 MB) [ 0.370568] < 0.003426> Stack space : 0xa3ef8000 -> 0xa3f0 (size 32 kB) [ 0.445993] < 0.075425> running /env/bin/init... [ 0.870592] < 0.424599> [ 0.874559] < 0.003967> Hit any key to stop autoboot: 0 [ 1.326621] < 0.452062> loaded zImage from /dev/nand0.kernel.bb with size 1679656 [ 2.009996] < 0.683375> Uncompressing Linux... done, booting the kernel. [ 2.416999] < 0.407003> Linux version 2.6.31-rc4-g056f82f-dirty (s...@octopus) (gcc version 4.3.2 (OSELAS.Toolchain-1.99.3) ) #1 PREEMPT Thu Aug 6 08:37:19 CEST 2009 [ 2.418729] < 0.001730> CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177 [ 2.423081] < 0.004352> CPU: VIVT data cache, VIVT instruction cache [ 2.426592] < 0.003511> Machine: phyCORE-i.MX27 [ 2.430609] < 0.004017> Memory policy: ECC disabled, Data cache writeback [ 2.439704] < 0.009095> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [ 2.463977] < 0.024273> Kernel command line: console=ttymxc0,115200 mt9v022.sensor_type=color ip=192.168.23.197:192.168.23.2:192.168.23.2:255.255.0.0::: ubi.mtd=7 root=ubi0:root rootfstype=ubifs mtdparts="physmap-flash.0:256k(uboot)ro,128k(ubootenv),3M(kernel),-(root);mxc_nand:256k(uboot)ro,128k(ubootenv),3M(kernel),-(root)" [ 2.467580] < 0.003603> Unknown boot option `mt9v022.sensor_type=color': ignoring [ 2.471632] < 0.004052> PID hash table entries: 512 (order: 9, 2048 bytes) [ 2.479971] < 0.008339> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [ 2.485485] < 0.005514> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [ 2.485560] < 0.75> Memory: 128MB = 128MB total [ 2.490595] < 0.005035> Memory: 126108KB available (3104K code, 350K data, 100K init, 0K highmem) [ 2.494609] < 0.004014> NR_IRQS:272 [ 2.494654] < 0.
Re: flicker free booting
On Fri, Jul 31, 2009 at 12:48:37PM -0700, Tim Bird wrote: > > Those fractions-of-seconds boot times are beyond the reach of the > > 200 MHz-class ARM9 processors and similar, where it takes two or > > three seconds just to load and uncompress the kernel from NOR or > > NAND flash. > > While I don't disagree from a practical standpoint - at Sony using XIP > we have been able to finish kernel boot on a 192 MHZ ARM9 in 186 > milliseconds. In the lab, anyway? Wow, that's pretty fast; if that would be possible for standard scenarios, it would indeed be better to do everything on the kernel side. Can you elaborate about the details of that experiment? Was that normal XIP from NOR? What size has this kernel been? rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: flicker free booting
Hi David, On Fri, Jul 31, 2009 at 11:03:10AM -0700, David VomLehn wrote: > On Fri, Jul 31, 2009 at 05:53:52PM +0200, Robert Schwebel wrote: > > On Tue, Jun 02, 2009 at 08:35:35PM -0700, Greg KH wrote: > > > On Tue, Jun 02, 2009 at 11:34:52PM +0200, Robert Schwebel wrote: > > > > Could flickerfree-bootsplash be a topic? Or is that completely > > > > pushed into the userspace these fastboot days? > ... > > So what I would like to see is this: > > > > a) power on > > b) almost immediately (< 1s) a splash screen appears > > c) optionally be able to do some animation, progress bar etc > > d) application appears (instantanously or by fading) > > This is an issue that I think is common to many embedded platforms, but I'm > not sure this is the solution. (I'm not sure it's *not* the solution, either). I hope it is more a call-for-discussion :-) > The question I've been looking at is: do sub-second boot times make > all this a moot point? After all, if you can bring up your graphics > driver in a fraction of a second and use *it* to display a splash > screen, it seems like it would meet your need to give almost immediate > feedback to users that the system is alive. Yup, that would be cool. However, on flash-based systems in the ARM926 / 200...400 MHz class (which is still quite common) the boot time up to the point where the penguin appears is still about 3...4 s [1] which is too long. So I suspect until systems become faster, we'll have no other choice than such as scenario. rsc [1] we can do some benchmarking next week -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: flicker free booting
On Tue, Jun 02, 2009 at 08:35:35PM -0700, Greg KH wrote: > On Tue, Jun 02, 2009 at 11:34:52PM +0200, Robert Schwebel wrote: > > Could flickerfree-bootsplash be a topic? Or is that completely > > pushed into the userspace these fastboot days? > > We have that working today, no in-kernel work needed other than the > already-present KMS stuff. See the recent Moblin images for proof of > this. Well, I assume that the issue you've addressed is being flicker free between the kernel and x.org; what I mean is flicker-free even with the bootloader in mind. What we want to address is another problem which is present on almost all display-enabled SoC-type embedded hardware. This kind of hardware is BIOS-free and is booted from an embedded bootloader like u-boot. These processors are often pretty slow, being in the 200 MHz ARM926 league. The boot scenario on these boxes looks like this: 1) power-on 2a) on NAND-only systems, pre-bootloader is fetched from NAND block 2b) bootloader starts from NAND or NOR flash 3) the bootloader fetches Linux from NAND/NOR flash 4) kernel starts 5) userspace starts 6) application starts (i.e. app against qt+dfb or gtk+dfb) These SoCs are usually built into "devices" which don't look like PCs; think of it as mobile phones (although our applications are usually more industry-style, like machine controllers, measurement systems etc). Most industry applications have been built with microcontrollers + 2x16 alpha numeric displays in the last generation; this type of hardware has a boot time (from power-on to full operation) of something like 0.5 s. So what I would like to see is this: a) power on b) almost immediately (< 1s) a splash screen appears c) optionally be able to do some animation, progress bar etc d) application appears (instantanously or by fading) At the moment, we do this by using random hacks in the kernel, which is pretty bad. So what I'm searching for is a clean API which may be accesptable form the Linux mainline. Here's a proposal from my kernel team: - u-boot initializes framebuffer on some + shows image - kernel commandline: mem=127MB framebuffer=:: The framebuffer is reserved at the given address (i.e. 1 MB at the upper end of the memory, so we have to reduce the overall memory available for Linux) - kernel driver recognizes that the framebuffer was already set up and skips the initialisation step (which would otherwhise result in flicker) A second step could be: - Have this initial framebuffer as /dev/fb0 (mem at the end of RAM) - In order to avoid flicker, the driver sets up a 2nd framebuffer, in dynamically allocated memory -> /dev/fb1. This framebuffer continues to display the splash image (or an animation). Switching from fb0 -> fb1 is done during VSync. - While the splash image is still visible in fb1, the application starts, up to the point where it shows it's main screen. This usually never works flicker-free, but we don't see it, as fb1 is visible. - switch back to fb0 (during a VSync to avoid flicker) - optionally discard fb1 ressources On some hardware, the switch could be done by fading from fb1 to fb0 (i.e. on i.MX27 this should be possible). Drivers which see the framebuffer= parameter would have to skip their hardware initialisation step. What do you think? Would something like this be acceptable? Other ideas? rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 Tue, Jun 02, 2009 at 10:10:58PM +0100, Russell King wrote: > I really don't think combining SoC support is going to be realistic, > device tree or not. When we had just four machine types (RiscPC, > EBSA110, EBSA285, Netwinder) I did look into this and came to the > conclusion that it would be far too inefficient for there to be any > win. > > The big problem we have is that the only commonality between different > SoCs is that the CPU executes ARM instructions. Everything else is > entirely up to the SoC designer - eg location of memory, spacing of > memory banks, type of interrupt controller, etc is all highly SoC > specific. Nothing outside of the ARM CPU itself is standardized. And even with the cpu core, we usually build kernels with optimized toolchains for their cpu family. But nevertheless - describing hardware inside a mach* makes sense. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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
On Tue, Jun 02, 2009 at 03:37:44PM -0500, James Bottomley wrote: > The topic of "flattened device tree" look interesting to me (perhaps > because I'm a hardened device driver person and things like that > always look interesting to me) ... The recent oftree activities look indeed very promising; the different boot-information-passing methods, mainly in powerpc and arm land, is IMHO and important field where a generic kernel infrastructure would make sense for the embedded people. Taken that oftree has created robustness and compatiblity problems in the past but seems to move into a good direction recently, feedback from core kernel developers would certainly be a good thing. > if we can get a few more like that out of the woodwork, this approach > might end up being successful. Could flickerfree-bootsplash be a topic? Or is that completely pushed into the userspace these fastboot days? rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: Getting physical addresses of mmap'd pages from userspace
On Tue, Oct 14, 2008 at 10:47:06AM -0500, Bill Gatliff wrote: > One would think that in the world of high-technology, there would be a > huge upside to making products easy to use, which would naturally > require free availability of documentation and code (among other > things). But vendors seem to work contrary to that objective, which > must mean that there's an even bigger upside to NOT making a product > easy to use. Your argumentation neglects the possibility that vendors just do it the way they always did. Don't assume that some intelligent life form has mandatorily taken an intentional decision :) rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: Getting physical addresses of mmap'd pages from userspace
On Mon, Oct 13, 2008 at 11:58:20AM -0400, George G. Davis wrote: > It comes down to decisions of bill-of-materials and performance, the > MBX/SGX options mentioned already are part of the SoCs and have high > bandwidth connections to the processor. External options increase cost > and won't match bandwidth of on chip options, but that's just my > ignorant opinion w/o looking at the low-level detail comparisons. > Unless you intend to encourage the SoC vendors to use the SM50x > instead? : ) Of course, that won't help for the current and planned > generation(s) of devices... The BoM argument is probably true for high volume consumer or automotive use cases. For industrial usage, long term maintainability and thus availability of documentation and code is usually a more important argument. Just my 0.02 ct. I'm just a poor open source guy :) rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: Getting physical addresses of mmap'd pages from userspace
On Mon, Oct 13, 2008 at 07:50:08AM -0500, Bill Gatliff wrote: > Robert Schwebel wrote: > > In reality, there are no real alternatives for accelerates chips. > > Would the Silicon Motion SM50x chips qualify as an alternative? > > They can do the blitting, at least. No OpenGL, tho. So, I guess it > depends on your definition of "accelerated"... Yup, from our perspective it would be fine. Unfortunately, the hardware people in our project had (subjective, imho) concerns. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: Getting physical addresses of mmap'd pages from userspace
On Mon, Oct 13, 2008 at 09:28:15AM +0200, Thomas Petazzoni wrote: > > We are working on DirectFB [1] support for the PowerVR MBX & SGX > > chips these days, so I know the problem :) Our hardware platform is > > i.MX31 with the MBX, MPC5121e also with MBX (both freescale) and a > > TI OMAP with the SGX. > > This is interesting. Is this work available somewhere? Is it > open-source, or does it rely on proprietary drivers? It will be available when we have something which is worth being reviewed in public. As there is currently no possibility to get any documentation about the cores without NDAs, an open *driver* is IMHO not possible, so we'll have to rely on the proprietary drivers Freescale deliver. Bad, but I don't see another chance by now. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: Getting physical addresses of mmap'd pages from userspace
Tom, [Please configure your mail client to break likes @ column < 80] On Mon, Oct 13, 2008 at 08:33:25AM +0200, Tom Cooksey wrote: > On Friday 10 October 2008 21:12:13 Robert Schwebel wrote: > > On Fri, Oct 10, 2008 at 06:15:05PM +0200, Tom Cooksey wrote: > > > Is there any way to get the physical address of mlock()'d memory > > > from userspace? > > > > What do you want to do? I don't really see a reason to do such > > strange things any more these days. > > It's quite an annoying problem actually. Basically I have binary > drivers for Imagination Technologies's PowerVR graphics drivers. We > have tried very hard to get the source code for these drivers and have > failed. Eventually ImgTec allowed us to sign an NDA to get the headers > for one of their user-space libraries. This library allows us to > direct the graphics hardware to render to a specific physical memory > region. The problem is that there's no way to find out what the > physical addresses are which we need pass to the graphics hardware > (via the user-space library). Allthough the library allows us to > allocate emory, what I want to do is then blit that memory in a > different process. So a client process renders into an off-screen > buffer and the server process blits that buffer to the framebuffer. By > allowing the server process to do the blit rather than the client > process, we can get semi-transparent GL windows. > > The synchronisation we can do, it's the memory allocation I'm > struggling with. If we ask the library to allocate the memory for us, > we don't get the physical address to pass to the server process. > Instead, we need to allocate memory ourselves and pass the physical > address to the library. But like I say, I can't find a way to get the > physical address from the kernel. > > I realise getting round closed-source drivers isn't exactly encoraged, > but sadly, we really have no choice. :-( We are working on DirectFB [1] support for the PowerVR MBX & SGX chips these days, so I know the problem :) Our hardware platform is i.MX31 with the MBX, MPC5121e also with MBX (both freescale) and a TI OMAP with the SGX. The whole NDA and Licensing situation is annoying, but we have to live with it; if you ask me as a community person, I'd say "vote with your dollars". If manufacturers don't want to open their specs to allow people writing driver, it must mean that they don't want to sell chips. In reality, there are no real alternatives for accelerates chips. Regarding the technical question, dok might have an idea. He's currently working on DirectFB drivers ontop of the proprietary drivers in one of our projects. Cc'ed him. rsc [1] Sidenote: we have Gtk+ and TTFNAQ [2] running on top of DirectFB, with 2D acceleration. [2] The-Toolkit-Formerly-Known-As-Qtopia -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: Getting physical addresses of mmap'd pages from userspace
On Fri, Oct 10, 2008 at 06:15:05PM +0200, Tom Cooksey wrote: > Is there any way to get the physical address of mlock()'d memory from > userspace? What do you want to do? I don't really see a reason to do such strange things any more these days. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: ELBS mindshare
On Wed, Sep 17, 2008 at 03:48:57PM -0400, Bill Traynor wrote: > > On Wed, Sep 17, 2008 at 11:13:23AM -0700, Grant Likely wrote: > >> BTW, I was talking with a guy from TI last night (Mike Turquette; works > >> on the OMAP) and I asked him my standard question about what he thinks > >> about the state of building root filesystems for embedded systems. > >> > >> When he listed the toolkits he knows about and is interested in, ELBS > >> was either the 2nd or 3rd tool that he mentioned. > >> > >> Word is getting around dude. > > > > What is ELBS? If it is somehow better than ptxdist, I'll have to apply a > > few patches there 8-) > > Embedded Linux Build System > http://debian.websterwood.com/elbs/ > > Article on LinuxDevices: > http://www.linuxdevices.com/news/NS5894411715.html Ok, you do native building, that's not what we do for ptxdist's standard root filesystems. But note that ptxdist itself is only a system to manage configurable rules which are being executed in a dependency-defined order; so in the end, it can built whatever it likes. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: ELBS mindshare
On Wed, Sep 17, 2008 at 11:13:23AM -0700, Grant Likely wrote: > BTW, I was talking with a guy from TI last night (Mike Turquette; works > on the OMAP) and I asked him my standard question about what he thinks > about the state of building root filesystems for embedded systems. > > When he listed the toolkits he knows about and is interested in, ELBS > was either the 2nd or 3rd tool that he mentioned. > > Word is getting around dude. What is ELBS? If it is somehow better than ptxdist, I'll have to apply a few patches there 8-) rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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 Fri, Aug 08, 2008 at 09:42:41AM -0700, Fundu wrote: > First off i have a ppc based board. > and i'm trying to load a kernel image with ramdisk rootfs. Why? You can also boot your root fs for example directly from a flash partition. > i have build the kernel. it spit uImage,zImage and vmlinux.gz That depends on your build system ... > 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)? An uImage can contain a kernel but also other things. Please check the U-Boot documentation for more details. zImage and vmlinux.gz are kernel images. You usually need only one of them, but the details do surely depend also on your build system. > 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 ? In U-Boot you can add a kernel command line by setting the bootargs environment variable. It's probably a good idea to start reading the U-Boot documentation, or whatever came with your board support package. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: [PATCH] bootup: Add built-in kernel command line for x86
On Wed, Aug 06, 2008 at 02:31:48PM -0700, Tim Bird wrote: > Add support for a built-in command line for x86 architectures. > The Kconfig help gives the major rationale for this addition. If this feature is desired on all architectures, shouldn't it go out of arch/? rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: [patch 2/4] Configure out file locking features
On Thu, Jul 31, 2008 at 10:31:26PM +0300, Adrian Bunk wrote: > > In the OSADL safety working group, people are discussing about Linux > > for safety critical applications. If we want to achieve such > > scenarios, stripped-down systems are an absolute must. > >... > > My first reaction is that as soon as you enable CONFIG_EMBEDDED you > can easily enter codepaths noone else has used for a while and that > got unnoticed broken. That may be no problem; if we ever come to a safety kernel, it will have to be audited and carefully tested anyway. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: [patch 0/4] [resend] Add configuration options to disable features
On Thu, Jul 31, 2008 at 03:46:28PM -0400, Josh Boyer wrote: > > I do not think of NTP as desktop or server application, but that's > > probably just me, > > No, it's not just you. NTP is useful in cases where things do care > about time but hardware designers were too cheap to put an RTC on the > board. Yes, we also have such customer systems, i.e. one which is used in a Telemetry application where you can have hundrets of PXA270 data concentrators that collect data from FPGAs and push them to a PC via ethernet. As the system does not work without the PC, the hardware designers decided that they can save hundrets of RTCs. Or another autonomous data collection system where only one system of several tens has an RTC... We used chrony in these cases, as the standard ntputils seem to be optimized for scenarios where you have permanent network connection, which is often not the case in embedded applications. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: [patch 2/4] Configure out file locking features
On Thu, Jul 31, 2008 at 10:32:20AM -0700, Tim Bird wrote: > > And for embedded systems with which applications is it 100% safe to > > disable this option? > > Sony's digital cameras. We have also several very small automation & measurement devices in the field which run a very dedicated more or less single application which can be carefully audited. In the OSADL safety working group, people are discussing about Linux for safety critical applications. If we want to achieve such scenarios, stripped-down systems are an absolute must. Although increasing processor power even in embedded applications lead to more and more standard-line kernels plus normal userspace components (i.e. glibc instead of uclibc), there are still applications where the final product consists only of the kernel plus the app, whereas during development time, the system has a full-blown configuration. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: AT91 kernel programming documentation ?
On Wed, Jul 30, 2008 at 03:53:19PM +0200, Stefan Schoenleitner wrote: > I'm looking for some good documentation concerning AT91 Linux kernel > development. Currently I have a Olimex AT91SAM9260 development board > which is supported by the at91 patch set. The base functionality is supported in the Linux mainline. > Now I would like to add different hardware to the board and write some > kernel code for it. What kind of hardware? > Unfortunately, there doesn't seem to be a lot of documentation. At > the moment I'm reading mach-at91 related source code and trying to > find out how things work. I assume you've already bought a copy of the Rubini Device Driver book? > Specificly, I would like to know how the different SoC devices can be > accessed and used, how I can do port multiplexing, how I can tell the > kernel which hardware is attached to where and so on. Check arch/arm/mach-at91/*. It very much depends on what you want to do. Documentation/drivermodel/ might also be worth a look. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: Useful IRC channels
On Wed, Jul 23, 2008 at 03:41:23PM +0500, Shaz wrote: > Can anyone indicate some useful and active IRC channels on embedded > Linux and cross compilations? I need to sort out some tit bits, which > are not feasible and relevant for this list in some way :) #ptxdist on freenode.net rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: building Rootfs
On Tue, Jul 08, 2008 at 05:52:34PM -0700, David VomLehn wrote: > We do this all the time. We have a very minimal root filesystem and > aren't currently using any of the frameworks for building root > filesystems, so everything is done with make. In general, we create tar > files for each piece. The piece that has device nodes has a make file > with something like: > > all: > fakeroot make fakeroot-package > > fakeroot-package: > mkdir -p image > mknod image/dev/null c 1 3 > mknod image/dev/random c 1 8 > tar -C image -czf image.tgz . That does work fine when packaging the rootfs on the host. It was the reason why we went the ipkg way: you can put device nodes into them. > We ran into some issues when we separated running mknod and tar into > separate fakeroot invocations because there is a bug in fakeroot with > exporting and importing its state. Fortunately, doing all of this under a > single fakeroot command works just fine. When we untar the tar files for > all of the pieces to create a root filesystem image and then run mkcramfs > to create a CRAMFS image, we do all commands under a single invocation of > fakeroot. > > No stage of the build requires running as root. The only stage we need root privileges in PTXdist is when creating a root filesystem which can be booted via nfsroot (which is common during development). In that case, you *need* /dev/console and /dev/null, which cannot be created by the user. We have solved that by using sudo there: the automatic build asks for the user password, but with a timeout. So in interactive builds, you can just enter the password and have a rootfs ready to be booted, and it still works with automatic overnight builds. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: building Rootfs
e installation > of ptxdist itself in say /usr/lib/ptxdist/patches, /usr/lib/ptxdist/... > then in my project space $HOME/project/... etc. Think of it as object orientation, written in make :-) For each packet (let's say bash), ptxdist brings it's own information with it: rules/bash.make rule set (what is to be done) rules/bash.in menu definition (kconfig) patches/bash-x.y/generic/ patch series (quilt format, canonical patches, following kernel rules) PTXdist brings a "set" of such packages with each installation of the tool itself (i.e. ptxdist-1.0.2 has it's own packet set). You can overwrite packages (make, in and patches) by simply putting them into the project. This makes it possible to change things in single packets, without the need to switch to a new ptxdist version. > I believe at archivicing time everything including ptxdist itself > is zipped up and archived on one storage media. But I need to > keep all files relating to a package in one place while developing, > and living like that for a long time. Since /usr/lib/ptxdist isn't even > being backed up normally, only NFS mounts like /home, I then > need to move the entire ptxdist into the SCM, which it clearly > doesn't like without a lot of hacking, plus, how would I > upgrade it? Archiving is pretty easy: all you need is: - the ptxdist tarballs you have installed from - all the source tarballs which have been downloaded on the first run of the "get" stages - your project workspace It was *desinged* to be easily archived, so this is exactly what has to be done. HTH, rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: building Rootfs
On Wed, Jul 09, 2008 at 01:53:46AM +0200, Linus Walleij wrote: > 2008/7/8 Wolfgang Denk <[EMAIL PROTECTED]>: > > >> 3. Getting files into the filesystem when the development > >> system does not allow root access. > > > 3. is a non-issue for most common file systems. > > The only one thing I ever ran into trouble with was device nodes, > these cannot be reproduced any way, not even with fakeroot > environments, just in scratchbox, which in turn needs you to be root. You can create an image with fakeroot which contains the device nodes, then flash it into the device as a normal user and boot it there. > initramfs etc can handle it with special description files. But if > you want to cook up say a .tar file of your rootfs, you're pretty > much lost AFAIK. Right, but it's no real issue. > The good thing is that you don't need the device nodes > if you have udev, I think the kernel wants /dev/console > and a few more at boot but actually it survives just fine > without them. Udev is pretty slow, so we have both possibilities in ptxdist. Users have a choice if they want to be as "normal" as possible (udev) or if they have faster requirements. For boot time optimized systems, we have even done mixed systems, with static device nodes in the (quick) boot phase and udev later on. > If you know some way of sneaking a device node into a .tar file > created ENTIRELY running as a regular user, tell me! The question is: why do you need a tar file? Hmm, I'm wondering if this discussion isn't off-topic here, as it is a kernel mailing list. But I know no other list anyway, so if nobody complains ... rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: building Rootfs
On Mon, Jul 07, 2008 at 06:24:48PM -0500, Haller, John H (John) wrote: > There are three issues in building an embedded cross-filesystem: > 1. Identification of the files to put into the filesystem. > 2. Stripping or extracting debug symbols from the filesystem. > 3. Getting files into the filesystem when the development > system does not allow root access. Ack. In PTXdist, we also cover 4. what to put into the initial image on deployment (we had what you describe in 3 above but split that up into "what to build" vs. "what to install" in ptxdist-2.x). 5. how to push the image into the device (managing and writing complicated u-boot environments and pushing it into the device automatically, via serial+ethernet) 6. automatic test suites against embedded targets > The first item is made a little easier by RPM, as it groups files > together into packages, and package dependencies are quite often > properly declared. However, packages sometimes have dependencies on > another package when only part of the package may be required. Another > problem is with documentation files (usually unwanted on an embedded > system), and locales which are huge and generally unwanted. That was the reason why we went with ipkg; the meta data of rpm and deb are too large to be hold on an embedded system, but we want software updatability. However, if someone needs any sort of Carrier Grade Blubberblabber, we could easily add rpm and/or deb :-) > The second item can be tricky, as one doesn't want to strip debug > symbols every time a filesystem is built, but the debug symbols are > generally needed for cross debugging. Yup; ptxdist solves this by having root/ and root-debug/, where the first one can be booted via NFS or flash, and the second one contains all the debug symbols. Cross debugging works that way, even with Eclipse (for the people who deny seeing the pure elegance and shinyness of vim and commandline gdb). > The third item is easy for an initramfs, but not well handled by > existing tools for an initrd (although I haven't looked recently). One > possibility is to modify a mkfs program, such as mke2fs, for the > filesystem of choice to accept proto files, like the traditional Unix > mkfs does. [Google mkfs proto for some examples]. I'm not sure if > ptxdist supports both initramfs and initrd. If you do have root > access, this is all much simpler, as an initrd can be locally mounted > and populated. I'm not sure as well; the parts for initramfs are there, but we don't use it here at Pengutronix, because all of our current customer systems have normal flash root filesystems; we once had a system with IXP425 that needed a userspace firmware for nfsroot, but that's the only case I can remember. However, if somebody needs improvement, he is free to send patches... > One other item that pops up sometimes is post-install scripts > that are associated with some packages. These scripts run in > the target filesystem, and there is no good way to run them > in the host environment. This is already solved :-) We have pre/post scripts, this way: rules/foobar.make rules/foobar.preinst rules/foobar.postinst ... In the scripts you can check if DESTDIR is set; if yes, you are in the host environment (development system tries to build a root fs from the ipkgs); if not, you are on the target (something does 'ipkg install'). With that mechanics, you can for example decide that on the target you need to stop a service first, then update, then start it again. Everything but update isn't required if only an image is being made. > This doesn't happen too often, so it can usually be handled by hand as > an exception. One example of this type of item is installing the > symbolic links in the right place for init scripts. Yup, that can be done with the mechanics above. > Using the tools from an embedded vendor has two problems - > they can change from release to release, We have a stable ptxdist-1.x series with long term bugfix maintenance for that ... even this stable series is completely open source, for everyone's download pleasure. > and they are proprietary tools that lock you into the vendor. No need to do so. Everything in ptxdist is GPL. If somebody wants to be locked to Pengutronix, we feel better if he does so because he has the warm and cuddly feeling that we solve his problems best ... which, by the way, doesn't work too bad. > But, they may provide a GUI, if you are into graphical presentations. Well, if someone absolutely needs a GUI, he can use gvim¹ :-) rsc ¹ Or even Eclipse & vmware, if your software department has a better feeling while using buzzword technology. -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amts
Re: building Rootfs
On Mon, Jul 07, 2008 at 10:34:11PM +0200, Linus Walleij wrote: > Robert, can you brief us of how ptxdist fits together with > OpenEmbedded? What does these two projects actually share? Where do > they do similar things in parallel for example? They are both build systems for userlands, or whole embedded linux systems. I cannot speak for OE as I don't really know it in detail. The idea behind ptxdist is executable documentation. If you use Open Source software for business critical industrial applications, having control over the source is an important thing. So our customers are usually able to reproduce their root filesystems with one "ptxdist go" directly from the sources. Our design criteria are - things are highly configurable - you have to find out what was done why - going the mainline way where ever possible - use proven technology (ptxdist is written in bash & gnu make) > I'm trying - real hard - to get an idea of how people out there prefer > to build their root filesystems in cross-compiled environments. Well, I still havn't seen a real argument against it. At least not for our usecases. > Rob Landley recently wrote up a small blurb on why native > compilation is the way to go, and a small roadmap on how > he intended to get there using e.g. Qemu and Firmware Linux, > c.f: http://www.landley.net/code/firmware/about.html > which finally won me over to that line of thinking. > Debian and friends obviously go this way now. Cool, so what do we do for platforms like Blackfin, or any of the random ARM processors out there, write qemu support first? Sorry, you cannot really suggest this. Not with Qemu being in such a crude state that it can not even be built with modern compilers. Being able to be cross compiled is actually a *feature* of unix software, be it autotoolized or not. And, in reality, the problems which usually come up in these 'build native' discussions are very often academic. > However, when it comes to the widespread and much fragmented ways of > cross-compiling a rootfs, including the stuff put together by > MontaVista, WR and all those animals in the forest, obviously based on > RPM (build systems I haven't put my hands inside, since they are > proprietary) there seems to be very little consensus. Well, the consensus is usually configure && make && make install. If people just wouldn't assume that they know it better than autotools ... But don't let us start a flamewar in this direction here. It doesn't bring us anywhere. > ptxdist stands out but do you get a lot of outside contributions for > it? As it looks it seems you're running it yourself. (Beware: I > haven't looked close.) Oh, we have quite a bunch of contributions from the outside, and almost 200 people on the mailing list. It goes up and down, there are times where we get more contributions from the customers, then from the community, but in general it works really good. Note that it is a tool to solve *our* problems (which consist of making reproducable embedded linux systems for our customers, while being able to fix problems as they arise). And it solves them very, very well. > What else is there out there for rootfs, really? A hack from every > embedded company there is? PTXdist doesn't invent something new, it just exercises the usual configure && make && make install canon, in a reproducable way. Nothing more and nothing less. It is completely open, being GPL, so you can freely choose if you accept realizing it being on the way to world domination or not :-) It's not even focussed on building root filesystems. We also use it to build cross compilers and well defined Eclipse installations. > I'm more after what people actually *use* and what is community driven > here, not so much opinions on what is best (which will probably be the > unwanted side effect of this mail anyway...) PTXdist is in use and community driven, so it migth be worth a look :-) rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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 Sat, Jul 05, 2008 at 01:05:33PM +0200, Stefan Schoenleitner wrote: > Where did you get your information from ? Thought I had read something like that, but if they say so ... > To quote one of the cirrus guys: > > "It is not being discontinued. We just will not be supporting the OS's > like Wince and Linux anymore. The linux part is supported mostly by > this forum and OE, and the cirrus-linux mailing list. Has it been different in the past? Last time we had an EP93 project (has been some time ago), the support for Maverick Crunch was horrible and cirrus' effort to support Linux mainline was almost 0. If you want to have something which has good community support, check what the mainline Linux kernel supports and base your stuff on that. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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 Sat, Jul 05, 2008 at 11:03:11AM +0200, Stefan Schoenleitner wrote: > for my project I would like to design an ARM9 based single board > computer (SBC) using the cirrus logic EP9302 CPU: As far as I know, Cirrus has discontinued the EP93 processors. I wouldn't base a new design on it any more. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Sat, Jun 14, 2008 at 01:07:49AM +0100, Jamie Lokier wrote: > Kernels, uclibc, busybox. All combinations can't be tested. But it's > still _very_ useful to compile in only those parts wanted. Kernel (and thus kconifg) is a critical mass project of it's own; however, kconfig does only solve the "configuration" problem. Autotools is much more. However, I was talking about userspace software. Core components have usually much different needs. > Media players with lots of optional formats and drivers are another. > (They also have considerable problems with their Autoconf in my > experience). Send patches :-) > Generally, anything with lots of parts that different applications > might not use, and space or library dependencies are an issue. According to my experience, the configure part of autotools is not it's problem. Its more - configure scripts are slow - libtool isn't sysroot/destdir aware - complex cross scenarios are not well supported (i.e. ace/tao, where the IDL compiler needs most of libace and has to be compiled for both, the "build" and "host" system) > > That's exactly what ptxdist does: add a Kconfig frontend to the > > configurable switches. It does it for the user's convenience, although > > the currently implemented method is really developer-unfriendly (but we > > care about our users first). > > I agree. (And it proved about not being able to test more > combinations: last time I tried to build ptxdist, an up to date > version (at the time), it failed in several places.) Did you tell the development team? We are known to fix 95% of the problems in this universe in less than 10 minutes :-) However, we have a stable policy in the meantime (1.0.x is in maintenance only mode, regularly tested and quickly fixed), and the team is really responsive. So it may be time to try it out again :-) > > autotools need only a shell and make > > No, that's true only for very simple packages. Ok, plus normal unix tools like sed and awk ... > Most packages need lots of additional libraries installed - and the > development versions of those libraries, for that matter. Too often > the right development version - not too recent, not too old. With the > wrong versions, there are surprises. Right. But this is the downside of being able to deal with all this complexity: every other build system would have the same problem. > You said about too many user-selectable options. Many large packages > _check_ for many installed libraries. Get them wrong, and you have the > same problems of untested combinations. Yup, auto-testing is usually a problem if you build cross stuff. > Sure, autotools by themselves don't need much. But that's not > interesting: Autotools are not used only by themselves. They don't need a special runtime environment other than shell. Other systems like Perl, Python, Java or whatever has the problem that anything other than the very core is not very well defined and ends up in the version hell. We have once tried to write our automated test system for embedded boards with python and xml; the idea was to have something fancy, new and with good code-reuse. In the end it failed because the pexpect package we used to do the pattern matching bitrotted so quickly that four months later all the fancy tests didn't work any more, because it is not part of the python core. In the meantime we have migrated our automatic testing stuff to use shell, ssh/rsh and kermit. It is rock solid, and the code reuse factor is at least as good as with anything else. > Have you felt uncomfortable shipping a package that does use Autoconf, > Automake and Libtool, knowing that the scripts generated by those > tools are huge compared with the entire source of your package? No :-) > Have you _written_ Autoconf tests recently? Yea, all our packages are autotoolized. > Made any shell / shellutils non-portability mistakes in the tests? Yea, it happens in ptxdist all the time. People report about problems, we add new tests and the next revision works even on Ubuntu :) > Have you _read_ a portable Makefile lately? Have you tried writing > one for a complex package, confident that it's portable to different > quirky makes, quirky shells and quirky tools, outside the parts which > you might use Automake for? > > That's a rationale for the project which is rewriting Autotools in GNU > Make, assuming that to be ubiquitous now, imho. (Not all interesting > systems have a shell either.) I have no problems with people writing fancy new things. It's just that most people who try to do something better than autotools have only a fraction of the features. Open Source is darwinism: if there is something better, let's use it. But compare apples with apples. &g
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Fri, Jun 13, 2008 at 11:25:23PM +0100, Jamie Lokier wrote: > A trouble with that is some packages have hundreds of user-selectable > options - or even thousands. I've not seen a package with thousands of user selectable options. It's not even desirable, because the more options you have, the more difficult it becomes to test all the combinations. > Some other packages _should_ have more options, but don't because it's > too unwieldy to make them highly configurable with Autoconf. Imho, > Kconfig would be good for more programs than it's currently used for, > and could be made to work with those --enable/--with options: you'd be > able to configure them entirely on the command line, or interactively > with "./configure --menu" (runs menuconfig), or with a config file. That's exactly what ptxdist does: add a Kconfig frontend to the configurable switches. It does it for the user's convenience, although the currently implemented method is really developer-unfriendly (but we care about our users first). But it's of absolutely no use to whine about the fact that the world is such a curel place. *If* Kconfig had been there 20 years ago ... *if* 90% of the packages out there would have been Kconfig instead of autotools... We have to live with *reality*, and reality is that autotools solve real world problems, and they offer *one* standard user interface to package building. I can cross build almost all autotoolized packages in exactly the same way and people are used to it. All other build systems I've seen invented their very special way of doing things, leading to wheel-reinvention all over the place. > The "make" / "make install" part is easy to retain even with other > build systems, using a trivial Makefile which calls the other tools. I still don't understand why all the scons, cmakes and jams out there don't even try to provide the *standard* user interface everyone is used to on a unix system. > Lots of packages need special tools or other software installed to > build them; this is no different. autotools need only a shell and make > Perhaps it might even be possible to write a very small, portable, > specialised alternative to Make which is small enough to ship with > packages that use it? Why on earth would one want to reinvent make? rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: cross-compiling alternatives
On Fri, Jun 13, 2008 at 08:45:09PM +0200, Bernd Petrovitsch wrote: > > Recent pkg-config supports sysroot. > > FC-6 has "only" 0.21. Solved in ptxdist by building the "right" pkgconfig as a host tool. > > So you simply build your .pc files as usual (w/o sysroot prefix) and > > set the sysroot prefix via env on the pkg-config call. Ah, great, must be a new feature. Will have to integrate that into ptxdist... at the moment we fix it with a wrapper script. > The problem is that the build-time (cross-)linker needs to find the > (cross-compiled) lib under > /my/build/host/target/environment/opt/foo/lib at link time and the > shared linker under /opt/foo/lib at run-time. pkg-config is fixable (our wrapper in PTXdist does the right thing wrt. buildtime vs. runtime paths). > Hmm, after digging into that old project, it seems that libtool and > the .la files were the problem. Right, libtool's paths are critical: libtools isn't sysroot aware, and it seems to be not easily fixable. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Fri, Jun 13, 2008 at 08:30:52AM +0200, Alexander Neundorf wrote: > Battle of Wesnoth is currently converted to both Scons and CMake, and > in the end they will decide about the winner. (since Eric is good at > arguing I guess it will be scons). The thing is that 'configure && make && make install' plus the usuall --enable-foo / --disable-foo / --with-bla=blub semantics is simply *the* standard way of configuring stuff for unix systems. You don't need fancy tools, you get cross compiling almost for free and unix people simply know how to use it. All the cool kids out there who think they know everything better usually start with "I hate autotools", then invent something which solves 0.1% of the problems (including their very special problem) and tell the rest of the world that their shiny new tools is *s cl*. Been there, seen that. I maintain > 500 packets in PTXdist and guess which ones make 90% of the problems. Hint: they are not related to autotools ... rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Fri, Jun 13, 2008 at 05:11:04AM +0200, Sam Ravnborg wrote: > Tom has started a nice project which he named: quagmire. > See: http://code.google.com/p/quagmire/ > > From the website: > quagmire is intended to replace automake and libtool. Unlike these tools > it requires GNU make and is written solely using GNU make > features -- no preprocessing is required. Last time I looked it had *at least* 0.1% of the autotools features supported :-) rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Thu, Jun 12, 2008 at 08:37:35PM +0200, Enrico Weigelt wrote: > ACK. One of the first things I did was replacing libtool and > kicked off broken-by-design macros like AC_TRY_RUN. This solved > at >80% of the problems for me. Instead of hacking around and inventing new things, you should have spent your time for improving libtool ... rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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: Cross Compiler and loads of issues
On Thu, Jun 12, 2008 at 10:52:44PM +0500, Shaz wrote: > I have been following "Re: [PATCH 0/1] Embedded Maintainer(s)" and > felt like asking that is there one good way to get a cross compiler > work. I tried buildroot, scratchbox and even openMoko with > openEmbedded but all of them had lots of issues and don't know which > will be the best alternative. There's also OSELAS.Toolchain: http://www.pengutronix.de/oselas/toolchain/index_en.html We try to be as close to mainline gcc/binutils as possible, and if there are issues, please report or send patches :-) > Anyways, I liked the idea of Qemu based cross compiler. Is it possible > for the inexperienced to get it working and emulate the exact model > and devices. No. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 -- 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
