History of embedded Linux
Hi, This is a little off-topic, but I have a bee in my bonnet about documenting where embedded Linux came from. As a starting point, I have written up a time line of key events, which is here http://embedded-linux.co.uk/embedded-history I am aware that there is a lot that I have missed, or misunderstood, so if you have a few minutes to spare perhaps you could have a look at it and tell me what I have got wrong. I am not sure where I am going with this, but I would like to use it as the basis of a longer document/web site/garden shed on the topic of the evolution of Linux as an embedded operating system. Oh, one last thing. If someone has some reasonably reliable figures of the numbers of Linux products shipped, that would be nice. Ideally I would like a graph that goes from zero in 1995 to NNN million in 2012. I know, its a dream, can't be done... Bye for now, Chris Simmonds -- 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: debugging multi threaded applicatiosn on arm - status?
On 17/06/11 10:39, Sam Ravnborg wrote: Is it possible to bebug multi-threaded applications using gdb on ARM these days? We have had trobules getting this to work - but I do not have the details at hand atm. I am just curious if this is supposed to work or not. We have an arm target running: 2.6.32.8 #1 PREEMPT CPU: ARM926EJ-S rev 5 (v5l) (Atmel AT91SAM9263) The kernel is only lightly modifed - mostly with a few propriatary drivers and a few driver hacks (not suitable for mainline). It is a long story why we use such an old version. Our applications uses threads and we use glibc 2.10.1 with NPTL enabled. So far we have survived using the powerfull printf debugging :-) Sam It works for me, using various ARM 926 and Cortex A8 chips and kernel versions from 2.6.27 to the present day. Which version of gbd do you have? gdb version 7.x works much better than 6.x in my experience. Chris Simmonds -- 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
On 22/10/10 00:20, Andrew Murray wrote: Hello, 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? Thanks, Andrew Murray From my experience, your statements are broadly correct. As has been pointed out, there are techniques to optimise the boot time in a system, but they are not very well known to the majority of engineers working on embedded Linux devices. The situation is not helped by the poor choices made by many board and chip level vendors who bundle a Linux tool chain and rootfs with their hardware. So, I believe that it is mostly a problem of education, starting with the chip- and board- vendors. Bye for now Chris Simmonds -- 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: mount ramdisk rootfs /etc directory to jffs2 filesystem.
Johnny Hung wrote: 2010/1/22 Marco Stornelli marco.storne...@gmail.com: 2010/1/22 Johnny Hung johnny.hack...@gmail.com: 2010/1/20 Marco Stornelli marco.storne...@gmail.com: 2010/1/20 Johnny Hung johnny.hack...@gmail.com: 2010/1/19 Matthias Kaehlcke matth...@kaehlcke.net: El Tue, Jan 19, 2010 at 02:17:22PM +0100 Ricard Wanderlof ha dit: I consider to use ramdisk as rootfs because worry about wrong operation in rootfs (is use jffs2 rootfs) and it will cause system boot up failed. Another query, does the syslogd/klogd log files also store in jffs2 rootfs? Write to jffs2 frequently will reduce flash life cycle. BRs, H. Johnny -- It seems there are a lot of file-systems I have to study :P. The same question is how to split my rootfs? Re-mount /etc, /var to another file-sysyem mtd part when system boot up? Yes, I know. So if I want set etc directoyr to /dev/mtd5 not in rootfs /, I need to add /dev/mtdblock5 /etcjffs2 defaults 0 0 in /etc/fstab file but rootfs doesn't contain /etc directory because /etc directoyr is store in /dev/mtdblock5. Do you know what I mean? The kernel execute /sbin/init after mount rootfs and /sbin/init is link to busybox, busybox will read /etc/inittab file to initial. The problem is coming, how busybox to read /etc in rootfs before mount /dev/mtdblock5 to /etc? There is no program to mount /dev/mtdblock5 to /etc before busybox init execute. I think I must mistake some concept, please give me a hint. Thank you BRs, H. Johnny You have two /etc directories: one in the the read-only root file system and one in the jffs2 fs. In the root fs you have /etc/fstab, /etc/inittab and any scripts it may call. The init program will mount /dev/mtdblock5 over the top of the /etc that is in the rootfs, so giving you the read/write version of /etc. Any files open in the old /etc - e.g. /etc/inittab - will continue to be open, but any new files opened in /etc will use the read/write version in jffs2. You can also do some interesting things with symbolic links... This technique works. I have used it in several projects. -- Chris Simmonds 2net Limited ch...@2net.co.uk http://www.2net.co.uk/ -- 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: [PATCH 06/14] Pramfs: Include files
Arnd Bergmann wrote: On Monday 22 June 2009, Marco wrote: Sorry, I meant it's not currently possible. At the moment the only way to use it as rootfs it's to copy all the data in an already mounted (empty) ram partition and reboot. However it's not my first item on my todo list because I think that it's possible to use it as rootfs but it isn't the standard use for this fs. Well, it doesn't have to work right away. What I'm asking to define the data structures in a way that keeps the layout stable across kernel updates. Since a future version of the file system might support cross-endian image creation, it would be good to define the data structures in a fixed endian mode already, so you don't have to change it in the future. Arnd -- 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 I disagree: that adds an unnecessary overhead for those architectures where the cpu byte order does not match the data structure ordering. I think the data structures should be native endian and when mkpramfs is written it can take a flag (e.g. -r) in the same way mkcramfs does. Chris Simmonds -- 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
