<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Werner Almesberger wrote:
<blockquote cite="mid:20080826152548.GC21401@almesberger.net"
 type="cite">
  <pre wrap="">Andy Green wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">solution here is to continue to do that by default and abort that if AUX
is seen during that time and go directly to backup kernel load.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Okay, let's try this. If the fallback choice is always the same as
the "magic key" choice, there's also no problem if loading the default
fails very rapidly.

  </pre>
  <blockquote type="cite">
    <pre wrap="">We already have better code than this with the kernel source structs and
it needs to work with that as I suggested.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Sure, that was just pseudo-code.

  </pre>
  <blockquote type="cite">
    <pre wrap="">I can't convince people that these commandline addons are not necessary,
putting them into the rootfs is not the worst way.  Although it means
one less point to kexec...
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Rootfs also has the advantage that they travel with their kernel.
E.g., if you had an SD card with a kernel that tries something with
initrd, and your normal card that doesn't, it would be very
inconvenient if you had to change anything else when swapping cards.

  </pre>
  <blockquote type="cite">
    <pre wrap="">But I don't like the way it still requires management of raw partition
in NAND case because we can't mount its rootfs.  Kernel magic partition
is bad enough.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Hmm, I don't see any way how we could really avoid having at least
one partition, i.e., the point we say qi is never going to grow
beyond.

Having access to that partition already means that we need to do the
math for sizing it and we need to have some way to convey the location
of the partition to our tools, be this through the mtdparts parameter
or some other means.

So it doesn't seem too horrible to apply this also a second time.

  </pre>
  <blockquote type="cite">
    <pre wrap="">NAND is once again the problem child needing more special pleading.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yeah, we can't escape it completely, try as we might. It's getting
much better, though.

  </pre>
  <blockquote type="cite">
    <pre wrap="">We could reduce the size of GTA03 backup rootfs and
go for mounting it jffs2 in Qi, then we unify the kernel location for
NAND too into being inside rootfs.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Heh, nice one :-) But are you sure you want to wrestle with JFFS2 ?
I thought you hated it too ;-)
  </pre>
</blockquote>
<br>
jffs2 has a serious startup penalty. I know you are talking about a
small fs, but still it would be better to use romfs don't you think?
you are talking about an initrd?<br>
<br>
</body>
</html>