On Tue, Jun 24, 2014 at 06:48:27AM +0200, Heiko Schocher wrote: > Hello Tom, > > Am 23.06.2014 17:05, schrieb Tom Rini: > >On Sun, Jun 22, 2014 at 09:36:43AM +0200, Wolfgang Denk wrote: > >>Dear Heiko, > >> > >>In message<53a67ed9.2090...@denx.de> you wrote: > >>> > >>>And I have no chance to detect this difference, when using > >>>"git am -3 ..." ... it just remains in the code ... > >>> > >>>I vote for copying the linux files, marking U-Boot specific code > >>>with __UBOOT__ ... > >> > >>Given the complexity of the code - and of the changes added in U-Boot > >>to the original (old) Linux code (which were done over a period of > >>time) - I think indeed that your original approach is the better one; > >>better both in the sense of requiring less efforts (for creating and > >>verifying that all chanes were covered), and less risk to miss > >>individual modifications either from the Linux or from the U-Boot > >>side. > >> > >>Scott, I agree that your suggestion is what usually should work fine, > >>but here it apparently fails in a number of places that would be time > >>consuming to sort out - and I would expect that the same would happen > >>again whenever we update to another new version of the Linux code > >>base. So I think we should stick with Heiko's approach here; it > >>documents clearly what he did, it looks complete, and it is working. > >>I think it would be a waste of time to redo all the work, just > >>differently. > > > >OK, lets try this. One worry at the back of my mind is the fallout we > >had when we re-synced to v3.7.1 and tested things as best we were able > >to prior to merge. I think it's too late in the cycle to pull this in > > Yes I fear such fallout too ... I could also test on some boards only, > the rest is compile clean only ... thats the reason why I had the sync > serie as RFC ... maybe we create a mtd-test branch? But on the other > hand, things maybe get tested only, if they are in mainline ... > > >for v2014.07, but lets get something in for v2014.10. And since v3.15 > > Yep, that was my plan too.
OK. > >is already out, lets do (as part of testing our theories out), a follow > >up patch to sync up with v3.15. And finally, I think we need, in order > >to keep this pain point down, sync per kernel release. > > Ok, I had prepared a v5, posting it soon. > > I try to do also to prepare a seperate sync with v3.15 patch, but give > me some time ... also I found a bug in current v3.16-rc1 kernel, using > ubi fastmap, see: > > "UBI: fix rb_tree node comparison in add_map commit buggy?" > http://lists.infradead.org/pipermail/linux-mtd/2014-June/054348.html > > So current v3.16-rc1 kernel could not attach a ubi volume using > ubi fastmap and created with a kernel not having commit > 604b592e6fd3c98f21435e1181ba7723ffc24715 applied ... which is > the case for v3.14 ... with my fixup, a v3.16-rc1 kernel could > again attach a v3.14 kernel or U-Boot (with my v3.14 sync patches > applied) created ubi volume ... > > Maybe we wait with the sync, until this is sorted out? Yes, that's fine. Perhaps we'll end up with a sync to v3.14 series, a v3.15 on top of it, and then backporting your bugfix patch(es) on top of that. > To sync us with each kernel release would be a good idea, but the > problem would be, to find time for it ... Yes, but I think if we do it more regularly it will be better for us and take less time. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
