[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#596889: flash-kernel: please add ARM-Versatile Express CA9x4 support



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



Reply to: