[Letux-kernel] Upstreaming GTA04.dts changes

[H. Nikolaus Schaller]

Hi Josua,

> Am 23.07.2018 um 17:15 schrieb Josua Mayer <josua.mayer at jm0.eu>:
> 
> Hi Nikolaus,
> 
> I am a little concerned by the model name changes.
> 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.
> Not a big deal though.

Ok, I see. This change makes devices a little better identifiable.

> 
> As to the ham1 vs. bch8 change, it nags inside me.
> If that gets accepted upstream, can it be marked as a fix for -stable releases? Because all of our u-boots used ham1, right?
> 
> The other thing that works in my mind is the fact that bootrom uses ham1 for reading the first 512 bytes (SPL),
> but the gpmc supports bch8 calculations so after those 512 bytes we could use bch8.
> However the knot in my mind is how to model that in DT:
> a) make spl partition read-only

Well, what would be the use of having it accessible in Linux at all?

> b) make ecc a property of the spl partition (is that even possible? Should it be possible?)

AFAIK this is not a partition-specific property so far but only one for the whole chip:

https://elixir.bootlin.com/linux/v4.18-rc6/source/Documentation/devicetree/bindings/mtd/partition.txt
https://elixir.bootlin.com/linux/v4.18-rc6/source/Documentation/devicetree/bindings/mtd/gpmc-nand.txt

> c) just use ham1 all the time to avoid this headache <-- I am sure this is what you want
> I haven't given the other parts a close look yet though.

This is probably the reason why BeagleBoard can use ham1 only. Despite the warning that the
NAND chip could do better. This is certainly not optimal, but on the other hand I have not seen
practical problems. As long as there are no bit errors at all, there is no need for correction and
every scheme is equally good. And bit errors raise with wear out, i.e. after reflashing. But the
rate we reflash these partitions isn't high. Except for the rootfs in NAND. But I don't know if
ubifs is using its own ECC scheme anyways.

BR,
Nikolaus

> 
> Am 22.07.2018 um 14:09 schrieb H. Nikolaus Schaller:
>> And here is a new version:
>> 
>> 	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>
>> 
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> http://projects.goldelico.com/p/gta04-kernel/ <http://projects.goldelico.com/p/gta04-kernel/>
>> Letux-kernel mailing list
>> Letux-kernel at openphoenux.org <mailto:Letux-kernel at openphoenux.org>
>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel <http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel>
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180723/69b7022b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180723/69b7022b/attachment-0001.asc>