[ptxdist] usplash and linux boot sequence
Hi ptxdist users, I'm currently attempting to build a linux kernel + userspace for a dedicated interactive application that is being developed. The application will run on a x86 PC integrated into the product. Since a display is attached, the desire is to have a graphic display shown to the user while the operating system application are starting up. The issue I'm facing is how to ensure that usplash is the first application that gets started. Since it assumes the /dev/.initramfs directory exists and remains existant. However, when udev starts, the /dev directory gets cleaned and prepared for booting. I'm not sure how I can handle this problem, when using busybox-init. My current solution is to load usplash after udev has already started and create the /dev/.initramfs directory for it. However, udev takes a few seconds to populate the /dev directory and load all the modules. Using the initramfs results in finally the entire project compiling. However I'm unable to get the initrd image I'm expecting. It seems I'm not understanding how that is exactly working. Does anyone have experience with this or can guide me to a solution for my problem? Thanks in advance! -- With kind regards, met vriendelijke groeten, cordialement, *Joris Dobbelsteen* _ Source of your development. Sioux Embedded Systems B.V. Esp 405 | 5633 AJ Eindhoven | The Netherlands KvK Eindhoven 17093039 T +31 (0)40 2677100 F +31 (0)40 2677101 E joris.dobbelst...@sioux.eu Visit us at: www.sioux.eu _ DISCLAIMER: The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Use cases for ptxdist's 'team feature'
On Mon, May 10, 2010 at 10:58:45AM +0200, Juergen Beisert wrote: When prebuild packages are used while development, how to ensure: - they are basing on the same ptxdist configuration - they are basing on a well known source code (no local modifications have been made by the developer who built the shared archive the first time) - they do not contain unknown dependencies enabled by the automatic decision of 'configure' to add feature A and B (because developer #1 enables some additional packages in his local BSP, not part of the shared configuration) - if changes are required (bug fixing for example) and where made on package's source code, are these changes already in the shared archive? Keep in mind: While development, all these archives are 'moving targets'. So, the risk is very high their content differs from the expected content. Th current packages implementation adds a md5sum to the package name. This md5sum is calculated from the PTXCONF options of the package. For a properly defined packages, this is enough to detect all external changes that influence the package. If not, the package is broken, and that is not something that can be detected with reasonable effort. Changes to the source code can in theory be detected if they are added as patches. The reason why it's not done right now is a technical one: It is too time consuming. The decision whether a package is built or extracted is made when make calculated the dependencies. Calculating a md5sum for the patches at that time adds several seconds to the ptxdist startup time. I thought about caching the md5sums, but when to refresh this cache? Can we assume that the patches in ptxdist wont change? We could cache those and recreate the md5sums for BSP/platform. There are usually only very few patches in BSP and platform. mol -- 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- | -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] usplash and linux boot sequence
Hi Joris I'm not sure how I can handle this problem, when using busybox-init. Does using upstart would help with this particular problem? Best regards Tim -- ptxdist mailing list ptxdist@pengutronix.de
