On Thu, Sep 23, 2010, Matt Waddel wrote: > > Don't think you actually need a tmp file since you don't prepend > > anything to the kernel; just mkimage $kfile directly. > > Removed the $tmp file creation.
Not sure it's ok to write the u-boot file to /boot; it's certainly writable, so I guess that's fine; I wouldn't like mkimage writing directly to the mtd as I would fear it would cause more flash erase cycles than strictly needed. > > but I need to note that I find this > > test quite bad for the mid-term. It means we're stuck with one kernel > > per-subarch. > > > > Perhaps we should check whether the corresponding kernel's config has > > support for this subarch instead? > > Isn't the subarch variable is just the last value of the kernel > name? So in this case "vmlinuz-2.6.35-1006-linaro-vexpress" => > vexpress. If there are other "tiles" that can connect to the > Versatile Express motherboard won't they have similar kernel > naming constructs? Wouldn't this mean we could have multiple > kernels per subarch? This is fine, the problem I mention arises when we want to build a single kernel for -omap and -vexpress boards for instance; in which case, your uname -r can't report either, and you can't test uname for subarch compatibility anymore. I guess we will cross that bridge when we get there > >> This shouldn't say "Linaro". I wonder if it would make sense to drop > >> "Debian" from all kernel/ramdisk references. > > I made this change by just removing "Debian" from "Debian kernel" and > "Debian ramdisk". Is that what you were looking for? Or do you > want me to add my own $kernel and $intrd variables? So to reply to tbm's comments; I think Debian/Ubuntu/Linaro etc. makes sense to include when you have multiple operating systems on a single box. Typically, if you have a Debian and an Ubuntu install, update-grub's os-prober will find the other install and include grub.cfg snippets to load either install so that you can start either system and all kernels it has installed from the GRUB menu. This doesn't really apply to flash-kernel because we allow booting only a single kernel; there is not menu whatsoever. So including some name doesn't matter too much IMHO. > Even if it's not zero padded it doesn't hurt u-boot. U-boot reads > the size of the initrd from the header and only copies the correct > size. So no calculations are required. Ok; that's good then. It would have been an issue with a raw initrd where the bootloader reads the whole partition and passes the size of the partition as initrd length to the kernel, but it's not the case -- Loïc Minier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100924090130.ga8...@bee.dooz.org
