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

[Linus Walleij]

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.

> 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.)

> 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.

>> 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...

Yours,
Linus Walleij