what about support wifi in bootloader?

Mike (mwester) mwester at dls.net
Thu Mar 19 15:21:42 CET 2009

Werner Almesberger wrote:
> Mike (mwester) wrote:
>> I think you have a flawed assumption -- neither ftp or http are reliable.
> Hmm, that's why you have CRCs at the layers below. Unless there's
> some specific bug that makes things worse than usual, I wouldn't
> really be concerned about FTP/HTTP/TFTP corrupting data.

That's *EXACTLY* the point, though.  Even the commercial gear has
issues[1] on this front, be they design flaws or bugs.  And home routers
and access points are full of bugs.  Not to mention the unknown issues
in the Freerunner's kernel, and any problems that might exist in the
busybox utilities that would be part of such a small rootfs/kernel
combo... and then there's the server side and it's handling of the data...

Do you _REALLY_ want to give such trust to all that code and all those
authors and engineers?

> Besides, your kernel generally has its own CRC anyway.

Sure, if someone wants to implement a utility that would check the
downloaded kernel for consistency post-download and pre-kexec-boot, that
would be a fine solution as well.


Let's not debate this issue; it's not about the theory of TCP and errors
and such, it's about reality.  Regardless of application, checksum your
downloads.  Check your md5sums.  Don't flash over wifi links.  I've
learned that's necessary on ALL networks of any type, with any data you
care about.

-Mike (mwester)

I have a collection of data from a year-long battle with an ISP over TCP
reliability.  They insist that TCP is reliable, and that the underlying
layers on their RF links are reliable, etc -- and yet I have numerous
traces that document bit-flips in large TCP downloads on their network.

They won't fix it (because apparently, despite all evidence to the
contrary, they also believe that TCP networks are inherently reliable --
it's really quite funny and sad to see them grasp for explanations for
the bit-flips and other documentation).  So now I have another ISP with
better equipment -- but I now also know that the TCP protocol itself
does not guarantee very much in terms of data integrity, and that even
commercial gear has trouble at the link-level and can pass bad data up.

More information about the openmoko-kernel mailing list