[Letux-kernel] 4.16 onenand
H. Nikolaus Schaller
hns at goldelico.com
Mon Apr 9 08:59:03 CEST 2018
> Am 09.04.2018 um 07:50 schrieb Andreas Kemnade <andreas at kemnade.info>:
> On Sun, 8 Apr 2018 22:36:12 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>> I just recognised that this
>>> Am 07.04.2018 um 22:41 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> Hmm, using one letux dtb, separately compiled. And then compile
>>> on plain mainline. There should be no reason why onenand should not
>>> work on mainline.
>> may be wrong.
>> If for example a patch between 4.16-rc0 and 4.16-rc1 changes some
>> omap3 SoC support driver (clocks, hwmods etc.) this might need
>> a change in omap3-something.dtsi as well.
> Well, old dtbs have to be compatible,
Hm. I am still not convinced that this assumption is correct. It is
like asking for some old module.ko to be compatible.
The reason I see is that there may be hidden changes we have no
responsibility for (and do not look for).
> so at least we will find
> something interesting.
> The only exception might be if our onenand dtb section was initially
No, there may be significant diffs in CPU/core setup we do not immediately see.
BTW: I have compared our OneNAND setup with the latest n950 and have not
spotted a difference.
Well, I don't know if the n950 uses omap3630/dm3730 or omap3430/3530.
Therefore the problem might be hidden in omap36xx.dtsi.
> And what also can be done: A diff between preprocessed dts of 4.16 and
Yes, that would be interesting!
> Probably I can do some bisecting this evening.
I have started to bisect my kernel panic...
The idea of rebasing letux-4.16-rc1 on top of letux-4.15.0 wasn't successful
because it started to ask for fixing rebase conflicts after 300 of 11000 patches.
I didn't want to fix them manually because that can introduce mistakes I will
only find at the end of the process...
So I switched back to bisect v4.15..v4.16-rc1. The most time consuming thing
is to setup the merge of required Letux patch sets. One thing is to find a minimal
set that can be compiled (we have some awkward cross-dependencies) and the
other problem are merge conflicts since I only have a rebased set of patches,
rebased on top of a newer linus/master than what bisect provides as the base.
Now I have a wrapper script for doing all that incl. bisect + clean-build + install
so that I just have to run the script, wait until it is done and then
take out the µSD, insert into the GTA04A5, apply the battery and watch
the console log to decide good/bad and start the script again. Takes
just 1 minute of manual work...
BTW: my script automatically does a 'git bisect skip' if it can't merge or
compile. This alone is quite helpful automation.
Currently I have 11 of 13 steps ahead and 1516 commits to test. So far all
were "bad" between 4.15.0 and 4.16-rc1.
More information about the Letux-kernel