<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Josua,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 23.07.2018 um 17:15 schrieb Josua Mayer <<a href="mailto:josua.mayer@jm0.eu" class="">josua.mayer@jm0.eu</a>>:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Hi Nikolaus,<br class="">
<br class="">
I am a little concerned by the model name changes.<br class="">
Debian flash-kernel uses that field to identify devices. So if it is
going to change, I should change my suggestion in the debian bug
report.<br class="">
Not a big deal though.<br class=""></div></div></blockquote><div><br class=""></div>Ok, I see. This change makes devices a little better identifiable.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">
<br class="">
As to the ham1 vs. bch8 change, it nags inside me.<br class="">
If that gets accepted upstream, can it be marked as a fix for
-stable releases? Because all of our u-boots used ham1, right?<br class="">
<br class="">
The other thing that works in my mind is the fact that bootrom uses
ham1 for reading the first 512 bytes (SPL),<br class="">
but the gpmc supports bch8 calculations so after those 512 bytes we
could use bch8.<br class="">
However the knot in my mind is how to model that in DT:<br class="">
a) make spl partition read-only<br class=""></div></div></blockquote><div><br class=""></div>Well, what would be the use of having it accessible in Linux at all?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">
b) make ecc a property of the spl partition (is that even possible?
Should it be possible?)<br class=""></div></div></blockquote><div><br class=""></div>AFAIK this is not a partition-specific property so far but only one for the whole chip:</div><div><br class=""></div><div><a href="https://elixir.bootlin.com/linux/v4.18-rc6/source/Documentation/devicetree/bindings/mtd/partition.txt" class="">https://elixir.bootlin.com/linux/v4.18-rc6/source/Documentation/devicetree/bindings/mtd/partition.txt</a></div><div><a href="https://elixir.bootlin.com/linux/v4.18-rc6/source/Documentation/devicetree/bindings/mtd/gpmc-nand.txt" class="">https://elixir.bootlin.com/linux/v4.18-rc6/source/Documentation/devicetree/bindings/mtd/gpmc-nand.txt</a></div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">
c) just use ham1 all the time to avoid this headache <-- I am
sure this is what you want<br class="">
I haven't given the other parts a close look yet though.<br class=""></div></div></blockquote><div><br class=""></div>This is probably the reason why BeagleBoard can use ham1 only. Despite the warning that the</div><div>NAND chip could do better. This is certainly not optimal, but on the other hand I have not seen</div><div>practical problems. As long as there are no bit errors at all, there is no need for correction and</div><div>every scheme is equally good. And bit errors raise with wear out, i.e. after reflashing. But the</div><div>rate we reflash these partitions isn't high. Except for the rootfs in NAND. But I don't know if</div><div>ubifs is using its own ECC scheme anyways.</div><div><br class=""></div><div>BR,</div><div>Nikolaus</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">
<br class="">
<div class="moz-cite-prefix">Am 22.07.2018 um 14:09 schrieb H.
Nikolaus Schaller:<br class="">
</div>
<blockquote type="cite" cite="mid:2C576B48-3BAD-4834-AEF7-A8CCCC21F7F3@goldelico.com" class="">
<pre wrap="" class="">And here is a new version:
<a class="moz-txt-link-freetext" href="http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work/hns/dt-upstreaming">http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work/hns/dt-upstreaming</a>
I have cleaned up all commits, did run checkpatch.pl and fixed
some minor issues. And I have checked that it compiles.
So basically the patch set looks good now and the first 32
commits are IMHO ready for upstreaming - unless you complain
before I submit them.
The missing bluetooth / fm sound nodes are not included in
the 32, so we can look for that independently.
BR,
Nikolaus
</pre>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
<a class="moz-txt-link-freetext" href="http://projects.goldelico.com/p/gta04-kernel/">http://projects.goldelico.com/p/gta04-kernel/</a>
Letux-kernel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Letux-kernel@openphoenux.org">Letux-kernel@openphoenux.org</a>
<a class="moz-txt-link-freetext" href="http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel">http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel</a></pre>
</blockquote>
<br class="">
</div>
_______________________________________________<br class=""><a href="http://projects.goldelico.com/p/gta04-kernel/" class="">http://projects.goldelico.com/p/gta04-kernel/</a><br class="">Letux-kernel mailing list<br class="">Letux-kernel@openphoenux.org<br class="">http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel</div></blockquote></div><br class=""></div></body></html>