Re: [Angstrom-devel] initramfs vs mtdblock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michal Panczyk schreef: | HI, | I was wondering what devices use boot parameter root=/dev/mtdblockXXX. | I am trying to figure out if there is a need for special fixing of | files in packages/initrdscripts/files/ dir to make these scripts aware | that some devices use plain "mtdX" (linux-handhelds-2.6) and some use | /dev/mtdblockX. This would help in work with initramfs stuff that I | try to launch on linux-2.6 devices (especially h5000). | So far I found following devices that have MTD_BLOCK=y in their defconfig: root=/dev/mtdblockX is the old way of accessing mtd devices, via a block emulation layer. The mtd folks now say you need to access it directly, via a virtual device: root=mtdX. The trouble with that is that the initramfs scripts look for *real* device nodes and can't find the mtdX ones, since they lack device nodes. There are two solutions that come to mind: * sed out 'block' when passing it to CMDLINE * use /proc/mtd to get the partitions and add in 'block' when probing fstype regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFH0ku8MkyGM64RGpERAsrFAKCLu8mI/OOjYnypwrgH2O2vKPhp4wCffK4E YsOWqk0IWRV3f7OOY5HVWyQ= =JJCz -END PGP SIGNATURE- ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] [Test fodder] initramfs images for h2200, h3900, h5000 and hx4700
Hello, On Thu, 6 Mar 2008 00:44:02 +0100 "Michal Panczyk" <[EMAIL PROTECTED]> wrote: > This helps with the menu - it gets reduced to 3 positions. jffs nfs > and shell. But I was not able to boot form mdt1 - it is looking for > mtdblock1 Message read from LCD : > ROOT_DEVICE=mtdblock1 > CMDLINE=keepinitrd root=mtdblock1 That's very strange - that should be /dev/mtdblock1 at least. Actually, it cannot be just "mtdblock1" except for when you pass root= on original kernel command line (from bootloader) - mere look at the code will prove that. > > (SNIP) loading modules > > "No valid root device was specified. Please add root=/dev/something to > the kernel command line and try again." > > About the patch : > We want to skip blockdevices and boot form mtdX - don't we ? Not quite. We want to remove mtdblock driver from kernel while still be able that boot with "dumb" kernel. Making initramfs to use fake device names for mounting might be a good optimization, but only an optimization - and initramfs-bootmenu can use lots of them. The functionality is still primary then. > Maybe the section > " if [ "$fstype" == "(jffs2)" ]; then > # ROOT_FSTYPE="jffs2" > ROOT_DEVICE="$dev" > fi" > Should somehow compare the partitions numbers ? mtdblock1 should go to > mtd1 and so on... Just haven't figured out how to do it in smart way > ... > > Lack of console is annoying too. This is cryptic at all. > Is boot_root() section init.sh (in packages/initrdscripts/files/) > responsible for that ? > "cd $BOOT_ROOT > exec switch_root -c /dev/console $BOOT_ROOT /sbin/init > " > How about changing /dev/console to something else (ie. ttyS0 ? ). > Another thing that has crossed my mind today - LAB has nice feature - > it there is no action taken it automatically scans for zImage and > tries to boot from media that provides it. It would be nice too - > especially after 100th boot when you don't want to choose again the > proper device to boot from... Obviously, that's one of the important functionality features to add before we'll be able to switch to it - I don't want to regress stuff for people who used to use LAB and other bootloaders. > > > From: Koen Kooi <[EMAIL PROTECTED]> > > Subject: Re: [Angstrom-devel] [Test fodder] initramfs images for > > h2200, h3900, h5000 and hx4700 > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Michal Panczyk schreef: > > > > > > | At this point - how to get params working out of the box? Some > > kind of | syncing between initramfs kernel and regular kernel is > > needed - get | both of them to support mtd1. Or maybe it is in the > > boot script | waitnig to pass the root value as /dev/$1 or > > something like that ? > > > > See (thunderbird damaged) patch at the bottom > > > > | Anther thing in that matter : > > | How to get the second kernel (or kexec - i don't know which one > > is it) | to be more talkative. Console gets silent after : > > > > I noticed that as well, it would be nice if boot messages can go > > over serial, since psplash obscures them anyway. > > > > | As it goes for the menu it can see following choices: > > | 0 : mtdblock0 (unknown) > > | 1 : mtdblock1 (jffs2) > > | 2 : mtdblock2 (unknown) > > | 3 : mtdblock3 (unknown) > > | 4 : NFS (nfsroot=192.168.2.200:/srv/nfs/oe/image) > > | 5 : shell > > | > > | Values 0 and 3 should get removed. > > > > I think uncommenting line 85 of the bootmenu script would > > accomplish that (see patch). > > > > | SD boot should be added. > > > > AIUI that gets added when it detects an sd card, so something else > > is wrong. > > > > | A reset option would be nice too. > > | > > | Where in oe is the script controlling that menu ? > > > > org.openembedded.dev/packages/initrdscripts/files/30-bootmenu.sh > > > > | The boot process: > > | I chose "1" and the screen blanked. Nothing else happened until > > now. I | am not sure if I did everything as it was supposed to be > > done. Judging | form Koen's experience the new zImage should just > > be linked to old | zImage in /boot dir. And that didn't work form > > me. | > > | The choice process itself is kind a hard - there are debug > > messages | comming in from the keys driver that make the screen > > unreadable, but | that is a different story. > > > > That's probably a simple kernel patch, Paul, Milan? > > > > As promised, the totally untested patch: > > > > > > # old_revision [16f0fa7ec858ba228dd9d241b0cff7a309a42dff] > > # > > # patch "packages/initrdscripts/files/30-bootmenu.sh" > > # from [b378e73bcd2daa97bd9e9134000a2ade7fe2538f] > > #to [5d48cde70bc16d340f2c5ad3ec825874bec7c228] > > # > > > > - --- packages/initrdscripts/files/30-bootmenu.sh > > b378e73bcd2daa97bd9e9134000a2ade7fe2538f > > +++ packages/initrdscripts/files/30-bootmenu.sh > > 5d48cde70bc16d340f2c5ad3ec825874bec7c228 > > @@ -82,7 +82,7 @@ while read maj min nblk dev;
Re: [Angstrom-devel] [Test fodder] initramfs images for h2200, h3900, h5000 and hx4700
Hello, On Tue, 4 Mar 2008 21:39:41 +0100 "Michal Panczyk" <[EMAIL PROTECTED]> wrote: > Hi, > > From: Koen Kooi <[EMAIL PROTECTED]> > > Subject: [Angstrom-devel] [Test fodder] initramfs images for h2200, > > h3900, h5000 and hx4700 > > Hi, > > > > As you may have read on the website news: > > > > > > http://www.angstrom-distribution.org/unstable/autobuild/h2200/zImage-initramfs-bootmenu-image-h2200-2.6.21-hh20-r14-h2200.bin > > > > http://www.angstrom-distribution.org/unstable/autobuild/h3900/zImage-initramfs-bootmenu-image-h3900-2.6.21-hh20-r14-h3900.bin > > > > http://www.angstrom-distribution.org/unstable/autobuild/h5000/zImage-initramfs-bootmenu-image-h5000-2.6.21-hh20-r14-h5000.bin > > > > http://www.angstrom-distribution.org/unstable/autobuild/hx4700/zImage-initramfs-bootmenu-image-hx4700-2.6.21-hh20-r14-hx4700.bin > > > > > > regards, > > > > Koen > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.5 (Darwin) > > > > iD4DBQFHzSexMkyGM64RGpERAhkGAKCgn+jaxjDvJnB25vrYjjsDn3IkWQCXTXwR > > cUzEml/cUWCvbbgXQtLRcg== > > =GCEc > > -END PGP SIGNATURE- > > Situation on h5000: > > On current images boot params are problematic. Recently, due to kernel > configuration change, root parameter was changed from /dev/mtdblock1 > to mtd1. Initramfs kernel tries to boot from /dev/mtdblock. and > that results in : > "initramfs: Loading /initrd.d/90-check-modules.sh module > No valid root device was specified. Please add root=/dev/something to > the kernel command-line and try again. > > sh: can't access tty; job control turned off > / $ " > > Changing linuxargs (in bootldr console or in /boot/params of jffs2 > image) to root=/dev/mtdblock1 helps. The initramfs menu shows up. That's not expected behavior! Passing "root=" on a kernel command line should skip showing menu and lead to the direct boot from the specified device. > > At this point - how to get params working out of the box? Some kind of > syncing between initramfs kernel and regular kernel is needed - get > both of them to support mtd1. While RFCing initramfs-bootmenu, I made explicit stress that there is not going to be "initramfs" kernel and "regular" kernel - this is going to be the *same* kernel. Why so? Is it required? Of course no, that's just important simplification measure, first of all designed to keep people from the confusion. > Or maybe it is in the boot script > waitnig to pass the root value as /dev/$1 or something like that ? No, no, and no. No "wanting", no magic. Value of root= is a value of root= as described in the kernel documentation. Anything working for "dumb" kernel should be working for initramfs-bootmenu. If that's not the case, please provide exact objective steps to reproduce it (objective steps are those "I pass kernel command line 'command line' to the initramfs kernel"). > > Anther thing in that matter : > How to get the second kernel (or kexec - i don't know which one is it) > to be more talkative. Console gets silent after : Again, no magic. "console=" kernel param responsible for that. initramfs-bootmenu passes all the original kernel parameters to the production kernel, only adding root= based on user selection. So, just console= properly, and you get what you want. And of course, if you have broken a bootloaders which passes crappy command lines behind your back, you should take your control back of the commandline still! > > "Kernel found in rootfs: > lrwxrwxrwx1 00 63 Jan 3 1970 > /mnt/boot/zImage -> > zImage-initramfs-bootmenu-image-h5000-2.6.21-hh20-r14-h5000.bin > /usr/sbin/kexec -f /mnt/boot/zImage > --command-line=mtdparts=ipaq:[EMAIL PROTECTED](bootldr)ro,[EMAIL > PROTECTED](root) > root=/dev/mtc That's good proof of what I wrote above. > [ 22.36] dmabounce: device samcop sdi on platform bus > unregistered [ 36.82] Starting new kernel > [ 36.82] Bye! > Uncompressing > Linux... > done, booting the k. " > > As it goes for the menu it can see following choices: > 0 : mtdblock0 (unknown) > 1 : mtdblock1 (jffs2) > 2 : mtdblock2 (unknown) > 3 : mtdblock3 (unknown) > 4 : NFS (nfsroot=192.168.2.200:/srv/nfs/oe/image) > 5 : shell > > Values 0 and 3 should get removed. As was described, they are debug output. > SD boot should be added. There's no such thing as "SD boot". initramfs-bootmenu allows to boot from any block device present in the system. If you have block device behind your SD card, you can boot from it. What should be added here is "Rescan partitions" menu choice. > A reset option would be nice too. Reset is a button on a device. > Where in oe is the script controlling that menu ? Well, by now you should be able to answer such questions yourself ;-). > The boot process: > I chose "1" and the screen blanked. Nothing else happened until now. Impossible. You should get log output on your console te
[Angstrom-devel] initramfs disappearing during kernel build: Solved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, This morning I sat down and looked at why the initramfs kernels fail to include an initramfs. I finally found out what is wrong. The kernel shows the following output: ~ GEN usr/initramfs_data.cpio.gz after which the initramfs is only 4kB big (aka an empty archive). ~From usr/Makefile: quiet_cmd_initfs = GEN $@ ~ cmd_initfs = $(initramfs) -o $@ $(ramfs-args) $(ramfs-input) That command will overwrite any existing initramfs_data.cpio.gz since the kernel was unpacked later than our initramfs_data.cpio.gz was created. I 'fixed' it by replacing cmd_initfs with 'echo'. The proper fix would have been to put the contents our out initramfs in some dir and have the kernel make its own initramfs_data.cpio.gz from that, but my way works as well :) Now we only need Thomas and Paul to combine their initramfs efforts to get one kickass initramfs for all machines with sucky bootloaders. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFH0mlCMkyGM64RGpERAuBoAKCyrzpLNsLBMB/Nl6JSV8vBpmjVCgCfbFNJ NsJwxd7Wc0bfZUMBqW0mAAs= =qDm6 -END PGP SIGNATURE- ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] initramfs disappearing during kernel build: Solved
> Now we only need Thomas and Paul to combine their initramfs efforts to > get one kickass initramfs for all machines with sucky bootloaders. Yes, and in the meanwhile please add an RFC for linux-rp initramfs implementation path. I think we should focus on some potential issues, because initramfs-bootimage is actually way too big for the limited space in mtd (at least for Zaurus). Thomas is working at it, developing a busybox-static using klibc. >From his work, two scenarios: 1) the initramfs-bootimage fits in mtd In this case we'd need a new recipe for the initramfs kernel: for the naming RP suggested "linux-rp-mini_2.6.2x.bb", including "linux-rp-mini.inc". This kernel would have own set of patches, helping to reduce the size. 2) the image doesn't fit, we'd use an initramfs-kexec image at first Then a new kernel+initramfs-bootmenu, unlimited in size and residing in /boot would be launched. No need for mini kernels this way, easy update when new kernels are released. Pro and Contra to discuss on the ml. My 2 cents Andrea ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] initramfs disappearing during kernel build: Solved
message got somehow truncated... On 3/8/08, Andrea Adami <[EMAIL PROTECTED]> wrote: > > Now we only need Thomas and Paul to combine their initramfs efforts to > > get one kickass initramfs for all machines with sucky bootloaders. > > Yes, and in the meanwhile please add an RFC for linux-rp initramfs > implementation path. > > I think we should focus on some potential issues, because > initramfs-bootimage is actually way too big for the limited space in > mtd (at least for Zaurus). > Thomas is working at it, developing a busybox-static using klibc. > > From his work, two scenarios: > > 1) the initramfs-bootimage fits in mtd > In this case we'd need a new recipe for the initramfs kernel: for the > naming RP suggested "linux-rp-mini_2.6.2x.bb", including > "linux-rp-mini.inc". This kernel would have own set of patches, > helping to reduce the size. > > 2) the image doesn't fit, we'd use an initramfs-kexec image at first > Then a new kernel+initramfs-bootmenu, unlimited in size and residing > in /boot would be launched. No need for mini kernels this way, easy > update when new kernels are released. > > Pro and Contra to discuss on the ml. > > My 2 cents > > Andrea > ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
[Angstrom-devel] simpad r9 x11 image has two kernels installed at /boot
Hi, I was testing the x11 r9 image and I am quite happy with it, but it contains the old 2.6.21 and new 2.6.14 kernel at /boot. Is it possible to remove the old one? best regards Bernhard Guillon ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] initramfs disappearing during kernel build: Solved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrea Adami schreef: |> Now we only need Thomas and Paul to combine their initramfs efforts to |> get one kickass initramfs for all machines with sucky bootloaders. | | Yes, and in the meanwhile please add an RFC for linux-rp initramfs | implementation path. | | I think we should focus on some potential issues, because | initramfs-bootimage is actually way too big for the limited space in | mtd (at least for Zaurus). | Thomas is working at it, developing a busybox-static using klibc. | | From his work, two scenarios: | | 1) the initramfs-bootimage fits in mtd | In this case we'd need a new recipe for the initramfs kernel: for the | naming RP suggested "linux-rp-mini_2.6.2x.bb", including | "linux-rp-mini.inc". This kernel would have own set of patches, | helping to reduce the size. | | 2) the image doesn't fit, we'd use an initramfs-kexec image at first | Then a new kernel+initramfs-bootmenu, unlimited in size and residing | in /boot would be launched. No need for mini kernels this way, easy | update when new kernels are released. | | Pro and Contra to discuss on the ml. First, let me state that we should aim to get the bootmenu image to be as small as possible (~100kB), regardless of which route we go with the above options. With that said, I think for the zaurus we should do: a) angelboot -> zImage + kexec -> zImage + bootmenu in flash -> rootfs or b) angelboot -> zImage + kexec -> zImage + bootmenu in flash -> zImage in rootfs or c) angelboot -> zImage + kexec -> zImage + bootmenu in rescue filesystem - -> zImage in rootfs d) buy an eeepc ~From a distribution point of view the options with a kernel in the rootfs get bonus points since it makes kernel upgrades so much easier. Option c) is particulary interesting, since we could opt to repartition flash and install our own rescue filesystem that is much smaller then the sharp one. Almost all options mean that generating an installkit will probably take more than one bitbake invocation (with bitbake 1.8.x), but that's not a real problem, since all angstrom buildscripts are available from the build tree. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFH0olGMkyGM64RGpERAsWzAKCh13V927H0Tr03F9E4KuW1SLzCMQCfQSoy HWc2XnqtQ7AHlkVN5G2/n9I= =PSZ3 -END PGP SIGNATURE- ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] simpad r9 x11 image has two kernels installed at /boot
Hello, On Sat, 08 Mar 2008 13:00:43 +0100 Bernhard Guillon <[EMAIL PROTECTED]> wrote: > Hi, > I was testing the x11 r9 image and I am quite happy with it, but it > contains the old 2.6.21 and new 2.6.14 kernel at /boot. > Is it possible to remove the old one? You should figure out what pulled in the old one. Usually, that happens when there's a module for old kernel which is no longer available for new kernel. If such module gets into image, it pulls old kernel. > > best regards > Bernhard Guillon [] -- Best regards, Paul mailto:[EMAIL PROTECTED] ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] initramfs disappearing during kernel build: Solved
Hello, On Sat, 08 Mar 2008 11:24:02 +0100 Koen Kooi <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > This morning I sat down and looked at why the initramfs kernels fail > to include an initramfs. I finally found out what is wrong. > > The kernel shows the following output: > ~ GEN usr/initramfs_data.cpio.gz > after which the initramfs is only 4kB big (aka an empty archive). > > ~From usr/Makefile: > > quiet_cmd_initfs = GEN $@ > ~ cmd_initfs = $(initramfs) -o $@ $(ramfs-args) $(ramfs-input) > > That command will overwrite any existing initramfs_data.cpio.gz since > the kernel was unpacked later than our initramfs_data.cpio.gz was > created. That's rather strange, because initramfs copying is handled by do_compile_prepend, and it worked for me as expected so far. > I 'fixed' it by replacing cmd_initfs with 'echo'. The proper > fix would have been to put the contents our out initramfs in some dir > and have the kernel make its own initramfs_data.cpio.gz from that, The reason I bothered to use internal kernel Makefile interface instead of external (CONFIG_INITRAMFS_SOURCE) because the former turned out to be easier than the latter! For CONFIG_INITRAMFS_SOURCE, we'd need to boringly adhoc-sed the defconfig, and then initramfs image must be stupidly provided as .cpio (not .gz). Again, once I saw that "drop initramfs in the magic place" approach worked from the first time, I didn't bother to break that ;-). Nonetheless, I committed small fixes to do_compile_prepend - clean initramfs unconditionally (so nothing stale could be picked) up and fixed that bashism... > but my way works as well :) > Now we only need Thomas and Paul to combine their initramfs efforts to > get one kickass initramfs for all machines with sucky bootloaders. > > regards, > > Koen [] -- Best regards, Paul mailto:[EMAIL PROTECTED] ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] simpad r9 x11 image has two kernels installed at /boot
Paul Sokolovsky wrote: > > You should figure out what pulled in the old one. Usually, that happens > when there's a module for old kernel which is no longer available for > new kernel. If such module gets into image, it pulls old kernel. > > There is /lib/modules/2.6.21/kernel/crypto/aes.ko as the only module in /lib/modules/2.6.21. In 2.6.21 defconfig file there is CONFIG_CRYPTO_AES=m set also in 2.6.24 defconfig. It seems aes.ko was renamed to aes_generic.ko from 2.6.21 to 2.6.24. How can I change it to use aes_generic.ko and not aes.ko? best regards Bernhard Guillon ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] initramfs disappearing during kernel build: Solved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sokolovsky schreef: | Hello, | | On Sat, 08 Mar 2008 11:24:02 +0100 | Koen Kooi <[EMAIL PROTECTED]> wrote: | |> -BEGIN PGP SIGNED MESSAGE- |> Hash: SHA1 |> |> Hi, |> |> This morning I sat down and looked at why the initramfs kernels fail |> to include an initramfs. I finally found out what is wrong. |> |> The kernel shows the following output: |> ~ GEN usr/initramfs_data.cpio.gz |> after which the initramfs is only 4kB big (aka an empty archive). |> |> ~From usr/Makefile: |> |> quiet_cmd_initfs = GEN $@ |> ~ cmd_initfs = $(initramfs) -o $@ $(ramfs-args) $(ramfs-input) |> |> That command will overwrite any existing initramfs_data.cpio.gz since |> the kernel was unpacked later than our initramfs_data.cpio.gz was |> created. | | That's rather strange, because initramfs copying is handled by | do_compile_prepend, and it worked for me as expected so far. The Makefile sees it as 'stale' and rebuilds it. |> I 'fixed' it by replacing cmd_initfs with 'echo'. The proper |> fix would have been to put the contents our out initramfs in some dir |> and have the kernel make its own initramfs_data.cpio.gz from that, | | The reason I bothered to use internal kernel Makefile interface instead | of external (CONFIG_INITRAMFS_SOURCE) because the former turned out to | be easier than the latter! For CONFIG_INITRAMFS_SOURCE, we'd need to | boringly adhoc-sed the defconfig, and then initramfs image must be | stupidly provided as .cpio (not .gz). Again, once I saw that "drop | initramfs in the magic place" approach worked from the first time, I | didn't bother to break that ;-). It works if 'cp' doesn't preserve the original mtime. Somehow it does do that on my machine. | Nonetheless, I committed small fixes to do_compile_prepend - clean | initramfs unconditionally (so nothing stale could be picked) up and | fixed that bashism... You didn't look at my fixes first ;) Now the .inc reads: ~rm usr/initramfs_data.cpio.gz [..] ~if [ -e usr/initramfs_data.cpio.gz ] ; then ~rm usr/initramfs_data.cpio.gz ~fi regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFH0qopMkyGM64RGpERAnJ0AJ98u6pQxJcf2h5rXWcq6107a+1nRwCcCDu4 cDiOuDKNK2INURRDf+39slE= =U+y1 -END PGP SIGNATURE- ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] initramfs disappearing during kernel build: Solved
Hello, On Sat, 08 Mar 2008 16:00:57 +0100 Koen Kooi <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Paul Sokolovsky schreef: > | Hello, > | > | On Sat, 08 Mar 2008 11:24:02 +0100 > | Koen Kooi > <[EMAIL PROTECTED]> wrote: > | > |> -BEGIN PGP SIGNED MESSAGE- > |> Hash: SHA1 > |> > |> Hi, > |> > |> This morning I sat down and looked at why the initramfs kernels > fail |> to include an initramfs. I finally found out what is wrong. > |> > |> The kernel shows the following output: > |> ~ GEN usr/initramfs_data.cpio.gz > |> after which the initramfs is only 4kB big (aka an empty archive). > |> > |> ~From usr/Makefile: > |> > |> quiet_cmd_initfs = GEN $@ > |> ~ cmd_initfs = $(initramfs) -o $@ $(ramfs-args) $(ramfs-input) > |> > |> That command will overwrite any existing initramfs_data.cpio.gz > since |> the kernel was unpacked later than our > initramfs_data.cpio.gz was |> created. > | > | That's rather strange, because initramfs copying is handled by > | do_compile_prepend, and it worked for me as expected so far. > > The Makefile sees it as 'stale' and rebuilds it. > > |> I 'fixed' it by replacing cmd_initfs with 'echo'. The proper > |> fix would have been to put the contents our out initramfs in some > dir |> and have the kernel make its own initramfs_data.cpio.gz from > that, | > | The reason I bothered to use internal kernel Makefile interface > instead | of external (CONFIG_INITRAMFS_SOURCE) because the former > turned out to | be easier than the latter! For > CONFIG_INITRAMFS_SOURCE, we'd need to | boringly adhoc-sed the > defconfig, and then initramfs image must be | stupidly provided > as .cpio (not .gz). Again, once I saw that "drop | initramfs in the > magic place" approach worked from the first time, I | didn't bother > to break that ;-). > > It works if 'cp' doesn't preserve the original mtime. Somehow it does > do that on my machine. Of course, just "cp" should not preserve timestamp, but set current time on the dest file! "cp -a" is what preserves timestamps and other stuff. If you think that your cp's behavior is anyhow grounded, please add explicit touch after copy, but I would think you'd hit breakage in many more places with such cp. > > | Nonetheless, I committed small fixes to do_compile_prepend - clean > | initramfs unconditionally (so nothing stale could be picked) up and > | fixed that bashism... > > You didn't look at my fixes first ;) Now the .inc reads: > > ~rm usr/initramfs_data.cpio.gz > > [..] > ~if [ -e usr/initramfs_data.cpio.gz ] ; then > ~rm usr/initramfs_data.cpio.gz > ~fi Well, I had them since the morning, and once tested fully pushed, there were no merge conflicts ;-). Feel free to update as needed. > > > regards, > > Koen [] -- Best regards, Paul mailto:[EMAIL PROTECTED] ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] initramfs disappearing during kernel build: Solved
First, let me state that we should aim to get the bootmenu image to be > as small as possible (~100kB), regardless of which route we go with the > above options. > > With that said, I think for the zaurus we should do: > > a) angelboot -> zImage + kexec -> zImage + bootmenu in flash -> rootfs > > or > > b) angelboot -> zImage + kexec -> zImage + bootmenu in flash -> zImage > in rootfs > > or > > c) angelboot -> zImage + kexec -> zImage + bootmenu in rescue filesystem > - -> zImage in rootfs > > d) buy an eeepc > How about: e) angelboot -> zImage + bootmenu -> zImage in rootfs I think this is possible if the bootmenu uses klibc and networking is disabled in first zImage. Regards, Thomas ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] initramfs disappearing during kernel build: Solved
Hello,
On Sat, 8 Mar 2008 17:28:46 +0200
Paul Sokolovsky <[EMAIL PROTECTED]> wrote:
[]
> Of course, just "cp" should not preserve timestamp, but set current
> time on the dest file! "cp -a" is what preserves timestamps and other
> stuff. If you think that your cp's behavior is anyhow grounded, please
> add explicit touch after copy, but I would think you'd hit breakage in
> many more places with such cp.
-KERNEL_INITRAMFS_PATH =
"${TMPDIR}/deploy/uclibc/images/${MACHINE}/initramfs-bootmenu-image-${MACHINE}.cpio.gz"
+KERNEL_INITRAMFS_DIR =
"${TMPDIR}/deploy/uclibc/images/${MACHINE}/"
+KERNEL_INITRAMFS_PATH = "${KERNEL_INITRAMFS_DIR}/$(readlink
${KERNEL_INITRAMFS_DIR}initramfs-bootmenu-image-${MACHINE}.cpio.gz)"
And this is also unnecessary by the same reason - cp should copy file
contents, unless explicitly asked to do something else, like copying
symlinks as is.
[]
--
Best regards,
Paul mailto:[EMAIL PROTECTED]
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] [Angstrom-distro-users] Poodle kernel 2.6.23 images available from the angstrom stable branch
On Friday 07 March 2008, Hans Henry von Tresckow wrote:
> If you want to help out your machine mentors by testing kernel 2.6.23
> for poodle, grab a 2007.12-r9 image from
> http://www.angstrom-distribution.org/unstable/autobuild/ , install it
> and tell us all about it.
WPA wifi won't work the opie* images, since the needed kernel crypto modules
(as defined by the task-base-extended package) are missing on poodle (and
probably on Akita and Spitz as well).
Interestingly in the x11 image they are included, as the x11-image.bb includes
"task-base-extended" in it's IMAGE_INSTALL variable.
Is the following (untested) patch the correct fix ?
Helge
--- packages/images/opie-image.bb a1c62875ee2fbe52f0ba014c4931559c768b671c
+++ packages/images/opie-image.bb cf7e5319c6dbd8b3b9423a721658be7c0d83ce3e
@@ -2,7 +2,8 @@ DEPENDS = "${MACHINE_TASK_PROVIDER} task
DEPENDS = "${MACHINE_TASK_PROVIDER} task-opie"
-IMAGE_INSTALL = "${MACHINE_TASK_PROVIDER} task-opie-base
task-opie-base-applets \
+IMAGE_INSTALL = "${MACHINE_TASK_PROVIDER} task-base-extended \
+ task-opie-base task-opie-base-applets \
task-opie-base-inputmethods task-opie-base-apps \
task-opie-base-settings task-opie-base-decorations \
task-opie-base-styles task-opie-base-pim \
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] initramfs disappearing during kernel build: Solved
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Kunze schreef: | First, let me state that we should aim to get the bootmenu image to be |> as small as possible (~100kB), regardless of which route we go with the |> above options. |> |> With that said, I think for the zaurus we should do: |> |> a) angelboot -> zImage + kexec -> zImage + bootmenu in flash -> rootfs |> |> or |> |> b) angelboot -> zImage + kexec -> zImage + bootmenu in flash -> zImage |> in rootfs |> |> or |> |> c) angelboot -> zImage + kexec -> zImage + bootmenu in rescue filesystem |> - -> zImage in rootfs |> |> d) buy an eeepc |> | How about: | e) angelboot -> zImage + bootmenu -> zImage in rootfs | | I think this is possible if the bootmenu uses klibc and networking is | disabled in first zImage. Does mtd + sd + pcmcia fit inside the kernel partition? I also want a beefier rescue system, so maybe I'm a bit biased :) regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFH0s8LMkyGM64RGpERAuMoAKCPlXgoVuIFZ2WBuypoabJuPdKV/ACfYbiS CXsupw5eUEb2JpWSaAxMuQg= =U4tL -END PGP SIGNATURE- ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] initramfs disappearing during kernel build: Solved
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Sokolovsky schreef:
| Hello,
|
| On Sat, 8 Mar 2008 17:28:46 +0200
| Paul Sokolovsky <[EMAIL PROTECTED]> wrote:
|
| []
|> Of course, just "cp" should not preserve timestamp, but set current
|> time on the dest file! "cp -a" is what preserves timestamps and other
|> stuff. If you think that your cp's behavior is anyhow grounded, please
|> add explicit touch after copy, but I would think you'd hit breakage in
|> many more places with such cp.
|
| -KERNEL_INITRAMFS_PATH =
|
"${TMPDIR}/deploy/uclibc/images/${MACHINE}/initramfs-bootmenu-image-${MACHINE}.cpio.gz"
| +KERNEL_INITRAMFS_DIR =
| "${TMPDIR}/deploy/uclibc/images/${MACHINE}/"
| +KERNEL_INITRAMFS_PATH = "${KERNEL_INITRAMFS_DIR}/$(readlink
| ${KERNEL_INITRAMFS_DIR}initramfs-bootmenu-image-${MACHINE}.cpio.gz)"
|
| And this is also unnecessary by the same reason - cp should copy file
| contents, unless explicitly asked to do something else, like copying
| symlinks as is.
It makes log.do_compile contain the full filename used, which I needed
earlier on :)
regards,
Koen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFH0tHtMkyGM64RGpERAmkrAJ9cAMEti7Q46HP7LJ5+UgyT5XEqvwCfXBlC
4+gc/jX+aiCfcf6FIJYzVVE=
=JC4/
-END PGP SIGNATURE-
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] [Angstrom-distro-users] Poodle kernel 2.6.23 images available from the angstrom stable branch
On Friday 07 March 2008, Hans Henry von Tresckow wrote: > If you want to help out your machine mentors by testing kernel 2.6.23 > for poodle, grab a 2007.12-r9 image from > http://www.angstrom-distribution.org/unstable/autobuild/ , install it > and tell us all about it. It seems the following patch is missing in -stable as well. It's already in -dev, but I don't have any number for the BACKPORTS file... Helge --- conf/machine/include/zaurus-2.6.inc 7ecb352669b5b71228489192cdeb5826dc02b46a +++ conf/machine/include/zaurus-2.6.inc f21df9dabb110dba413eec0c81e21d1b097a5756 @@ -35,7 +35,7 @@ MACHINE_EXTRA_RRECOMMENDS_spitz = "kern MACHINE_EXTRA_RRECOMMENDS_c7x0 = "kernel-module-snd-soc-corgi kernel-module-pxa2xx-cs kernel-module-pcmcia" MACHINE_EXTRA_RRECOMMENDS_akita = "kernel-module-snd-soc-spitz kernel-module-pxa2xx-cs kernel-module-pcmcia" MACHINE_EXTRA_RRECOMMENDS_spitz = "kernel-module-snd-soc-spitz" -MACHINE_EXTRA_RRECOMMENDS_poodle = "kernel-module-snd-soc-poodle" +MACHINE_EXTRA_RRECOMMENDS_poodle = "kernel-module-snd-soc-poodle kernel-module-pxa2xx-cs kernel-module-pcmcia" GUI_MACHINE_CLASS = "bigscreen" GUI_MACHINE_CLASS_collie = "smallscreen" ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] initramfs disappearing during kernel build: Solved
Hello, On Sat, 08 Mar 2008 11:24:02 +0100 Koen Kooi <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > This morning I sat down and looked at why the initramfs kernels fail > to include an initramfs. I finally found out what is wrong. > > The kernel shows the following output: > ~ GEN usr/initramfs_data.cpio.gz > after which the initramfs is only 4kB big (aka an empty archive). > > ~From usr/Makefile: > > quiet_cmd_initfs = GEN $@ > ~ cmd_initfs = $(initramfs) -o $@ $(ramfs-args) $(ramfs-input) > > That command will overwrite any existing initramfs_data.cpio.gz since > the kernel was unpacked later than our initramfs_data.cpio.gz was > created. I 'fixed' it by replacing cmd_initfs with 'echo'. Unfortunately, that doesn't seem to work with "rm" thing at all - that causes empty initramfs_data.cpio.gz to not being built by the kernel in case we don't supply external initramfs (for example, for uclibc kernel). So, I'm going to remove that patch and add explicit touch after copy, until you fix your cp ;-). [] -- Best regards, Paul mailto:[EMAIL PROTECTED] ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
[Angstrom-devel] initramfs-bootmenu-image update report
Hello, So, I spent today hacking on initramfs-bootmenu-image, and found (and made myself) few breakage here and there. With few people working actively on that area, there's some step-on-others-feet'ing happens, we kinda need 3 branches ;-D. So, main result is that kexec-tools-static in .dev appears to be broken - it doesn't pass command line to target kernel. Many issues can be attributed to that, including "recursive kexecing" as seen by Koen. It apparently became broken when Thomas switches it from uclibc to klibc, and yet he cannot reproduce the issue on collie, so it's possibly EABI-related. Bottom line: we should move as much (known working) stuff as possible to .stable, and I'd like to push linux-hh.bb initramfs support first of all (without activating it so far of course). Koen, can you check that r18 currently in .deb builds as expected for you? (Preferrably on something more sane than Ubuntu ;-) ). Otherwise, I did some hacking on initramfs-bootmenu itself, removing stray partition display and adding code to detect, ignore, and fix broken kernel environment as passed by bootldr and derivatives. Actually, I have just following 2 development items on the list before it IMHO will be ready for production: 1. Scan MTD partitions before others. So, they will appear first in the list, and the very first is of course going to be rootfs one. 2. Add timeout support for menu. So, with the above, production flash setups will continue to boot in unattended, while still easily allow to boot from other location with few key presses. -- Best regards, Paul mailto:[EMAIL PROTECTED] ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] Akita, c7x0, simpad, spitz and tosa kernel 2.6.24 images available from the angstrom stable branch
> If you want to help out your machine mentors by testing kernel 2.6.24 > for akita, c7x0, simpad, spitz or tosa, grab a 2007.12-r9 image from > http://www.angstrom-distribution.org/unstable/autobuild/ , install it > and tell us all about it. I would like to test a usb webcam with akita but I can't find the sn9c102 module in the feed. Any chance to get it added? rgds Morten H ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] initramfs-bootmenu-image update report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sokolovsky schreef: | Hello, | | So, I spent today hacking on initramfs-bootmenu-image, and found (and | made myself) few breakage here and there. With few people working | actively on that area, there's some step-on-others-feet'ing happens, we | kinda need 3 branches ;-D. | | So, main result is that kexec-tools-static in .dev appears to be broken | - it doesn't pass command line to target kernel. Many issues can be | attributed to that, including "recursive kexecing" as seen by Koen. It | apparently became broken when Thomas switches it from uclibc to klibc, | and yet he cannot reproduce the issue on collie, so it's possibly | EABI-related. | | Bottom line: we should move as much (known working) stuff as possible | to .stable, and I'd like to push linux-hh.bb initramfs support first of | all (without activating it so far of course). Koen, can you check that | r18 currently in .deb builds as expected for you? (Preferrably on | something more sane than Ubuntu ;-) ). Same old problem: [EMAIL PROTECTED]:/OE/build/tmp-new/angstrom/work/h2200-angstrom-linux-gnueabi/linux-handhelds-2.6-2.6.21-hh20-r18/kernel26/usr$ du * -hs 16K CVS 4.0KKconfig 4.0KMakefile 4.0Kbuilt-in.o 16K gen_init_cpio 12K gen_init_cpio.c 4.0Kinitramfs_data.S 4.0Kinitramfs_data.cpio.gz 4.0Kinitramfs_data.o -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFH05VUMkyGM64RGpERAnL8AKCE/xeAxCeioQUePYzTObPDoXsRlACdGl/F i+Jcv1d5hK0bvEIL4w8O4+M= =UCIt -END PGP SIGNATURE- ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
