[LEDE-DEV] [OpenWrt-Devel] Latest OpenWRT on Gemini v4.14

[Hauke Mehrtens]

On 02/27/2018 10:45 PM, Linus Walleij wrote:
> On Tue, Feb 27, 2018 at 4:46 PM, Hauke Mehrtens <hauke at hauke-m.de> wrote:
> 
>>> I have a forward-port hack-ish thing for Gemini,
>>> this 500K patch on top of openwrt HEAD:
>>>
>>> https://dflund.se/~triad/krad/gemini/0001-gemini-Forward-port-to-v4.14.patch
>>>
>>> It's ... big ... and just kills off the old v4.4 kernel support.
>>
>> Are most of the patches for kernel 4.14 already in mainline or on its
>> wait into the mainline kernel?
> 
> They are all taken directly from the v4.15 and v4.16(-rc3) upstream
> except for the last few patches that add USB support, which are
> hackish and may need some mods from Hans Ulli Kroll.

Good to hear that, so less patches we have to maintain. ;-)

Backporting patches from mainline kernel or adding patches into upstream
kernel is not mandatory but appreciated as this results in less
maintenance work for us.

>> Someone said he wanted to look into the gemini target as it was still on
>> kernel 4.4 and therefore on the list of targets which are getting removed.
>>
>> Can you please run "make kernel_oldconfig" to remove the unneeded
>> configuration options for the config-4.14 file.
> 
> I think it is fairly standard ... I first tried using
> arch/arm/configs/gemini_defconfig from the upstream kernel
> but OpenWRT didn't like/expect that, so I instead took the
> unaltered .config from the build tree, but that is essentially
> what comes out of the gemini_defconfig from upstream.
> 
> (Well I have a pending patch to the defconfig that the
> ARM maintainers seem to have forgot, but more or less.)

Felix already commended on this one.

>> And the also "make target/linux/{clean,refresh} V=99" to make the
>> patches cleanly apply.
> 
> I tested this and it looks clean.
> 
> They were all generated by cherry-picking Gemini development
> on top of a clean v4.14 from upstream so it is as clean as it
> gets.

"make target/linux/{clean,refresh} V=99" just converts the patches into
the "standard" format used for the patches in OpenWrt, when for example
someone updates the kernel 4.14.X to the next minor version this will be
run over all the patches for all targets. To decrease the number of
unrelated changes just run "make target/linux/{clean,refresh} V=99" now
once, it should still be possible to git am the patches and so on.

>>> And I can't test it on the Raidsonic aka IcyBox
>>> aka NAS4220B which is an important target.
>>
>> Could someone with devices supported by this target please test this and
>> report back if it is working or if there are any regressions.
> 
> Agreed!
> 
>>> NB: IF YOU'RE GONNA USE THIS, USE GCC 7.3.0 TO
>>> BUILD. The 5.5 toolchain doesn't work.
>>>
>>> Is there a way to require the 7.3.x toolchain?
>>
>> We want to use the same toolchain for all targets and a GCC bug on mips
>> was just fixed 2 days ago in upstream GCC.
>> I do not know if we will use gcc 7.X for the next release as this should
>> happen soon.
>>
>> What is the problem with gcc 5? I know that recent U-Boot versions do
>> not support it any more, mostly because the binary gets too big.
> 
> I have no clue what is wrong here, but the binaries get corrupt
> for Busybox. procd and a few others build and run fine.
> Took me ages to figure out that just rebuilding the whole
> thing with the 7.3.0 compiler made the problem go away...

Ok this is a strange problem.

Hauke