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: 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
[ANNOUNCE] barebox-2009.12.0 has been released
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 properly nand_imx_v2: Use a two staged scan process nand_imx_v2: Use generic bbt scan function pca100: remove imx_ prefix from
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
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
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 where lots of developers work with the board - and in that use
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
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=AttachFiledo=viewtarget=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
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: 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 Tue, Aug 18, 2009 at 12:34:52PM +0200, Alex Riesen wrote: On Tue, Aug 18, 2009 at 12:21, Robert Schwebelr.schwe...@pengutronix.de 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
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
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
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: [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: 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: 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 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
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 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: 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: [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 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: 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: 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
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 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 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 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 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
