[Letux-kernel] 4.16 onenand
H. Nikolaus Schaller
hns at goldelico.com
Sun Apr 8 15:03:19 CEST 2018
> Am 07.04.2018 um 22:41 schrieb Andreas Kemnade <andreas at kemnade.info>:
> On Sat, 7 Apr 2018 21:23:29 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>> Am 07.04.2018 um 19:52 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> On Sat, 7 Apr 2018 18:17:56 +0200
>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>>>> I am doing a clean rebuild of the first bad and the last good one. That
>>>>> all does not make too much sense.
>>> the behaviour is unstable,
>> Maybe should we try to bisect my kernel panic issue?
>> It seems to be very stable. At least from recent tests...
>> I have to bisect everything between v4.15.0 and v4.16.0
>> and merge into that all important gta04 patch sets, mainly
>> the dt and some others... If they cleanly apply which is
>> not always the case...
> 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.
>> And then compile and flash SD card. Needs ca. 1 hour per
>> run. And ca. 13 runs.
> Hmm, you need only make uImage, The kernel crashes before root is
> mounted, so no root and no modules are needed, just some ubifs in nand,
> you could directly use usb-start-kernel.sh (and do not forget to add
> the ubiattach stuff).
Ok, that would be simpler in this special situation.
> Probably 10 min per try or even less.
Yell, my machine is doing other tasks in the background so that
git and gcc are not that fast as they used to be.
Anyways, the best thing would be if we could rebase letux-4.16
on top of letux-4.15.
Then we should have a linear set of patches between real versions
(and not imitations) to search through.
>> Spending this time needs a little more thoughts about
>> priorities and alternatives.
> Well, looking at the weather forecast for tomorrow, I have a clear
> opinion what to do. And then I probably have a better idea,
> what to do.
Indeed. And the forecast is right.
Well, it does not stop me thinking :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Letux-kernel