Bug#413373: Patch for flash-kernel to improve speed
Hi Geert
On 3/4/07, Geert Stappers <stappers@debian.org> wrote:
My gut feeling[1] says it should be
So $tmp is unconditional overwritten with $ifile
You are essentially raising the issue that the flash-kernel code does
not currently handle initramfs files that are larger than 4 MB in a
clean way. In the current code, nslu2_swap will only succeed if the
size of the initramfs file is a multiple of 4 bytes. To ensure this
assumption is true, the initramfs is padded to 4 MB. That is, there is
the potential for an error if there are no padding bytes required.
Furthermore, the size of the mtdblock that contains the initramfs is 6
MB, so if the initramfs is greater than 6 MB (again no padding
required), the write will fail.
In the patch I submitted, $tmp will not exist if $pad is less than 0
(as you pointed out), and therefore the initramfs will not be written
to the flash. This situation is bad, because the kernel would have
already been written, but with either version of the code, the
potential exists for the mtdblock to contain an invalid initramfs
after the kernel has been written.
It seem that in the long term, the code should be modified so that if
either the kernel or the initramfs are too large to fit in the
mtdblock partitions, neither is written to the flash and a useful
error is reported to the user.
but I have no clue to what the 4M corresponds.
It is the arbitrarily chosen size to which the initramfs is padded to
ensure that the image can be endian swapped (AFAIK). I know that if
one tries to pad the initramfs to the size that is modulo 4 bytes
greater than the actual size (which seems that it should be all that
is required to swap the image), the kernel fails to recognize the
initramfs as a valid image. I don't know the reason for this behaviour
though.
Something else:
"isize" is not used in the proposed
+ dd if=$ifile of=$tmp ibs=4M conv=sync 2>/dev/null
not calculating $isize will also speed up flashing the kernel.
isize is still used. It is the parameter which is passed to sercomm_header.
Gordon
--
Gordon Farquharson
Reply to: