Re: [PATCH] gemini: Bump to kernel v5.10

2021-04-19 Thread Linus Walleij 
On Sat, Apr 17, 2021 at 1:46 PM Christian Lamparter  wrote:

> Do you have an update? I've queued your patch with "one weird trick"
> (use KERNEL_TESTING_PATCHVER instead of KERNEL_PATCHVER).
> 

Thanks!

> Yes, this will cause the buildbot to still built your target with 5.4
> but the 5.10 support will be there (behind CONFIG_TESTING_KERNEL).

I see the final committed version was on v5.10 KERNEL_PATCHVER
so I assume you developed confidence in it. :)

Well someone has to go first anyway, I hope we don't have too much
fallout. Gemini is really happy with v5.10 for sure.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] gemini: Bump to kernel v5.10

2021-04-17 Thread Christian Lamparter 

Hello,

On 15/04/2021 01:51, Linus Walleij wrote:

On Tue, Apr 13, 2021 at 11:37 PM Hauke Mehrtens  wrote:


The target kernel configurations should be small and most of the generic
settings should be done in the target/linux/generic/config-* config file.
The target configuration only contains the extra configuration options
or the options which are different.

(...)

You can add new generic options to target/linux/generic/config-5.10
manually.


OK I get it, I sent a slew of patches to the generic config.

We drive-by contributors just assume the generic config is
Perfect(TM) you know, now I realize I have to contribute to that
effort.



That was nicely worded... Yeah I know, there's no need for this.
In my case: That CoVID workload has bogged me down during the week.
I sometimes have a bit of spare-time on the weekends.

From what I can tell, the situation is: your gemini target would
be the first target that isn't "source-only" (which means it gets
skipped by the builderbots) that likes to fully switch to 5.10.
So you'll get all the fun of having to endure broken packages,
or have to come up with fixes for other stuff to make the buildbot
happy.

This might look overly cautions, but when I foolishly "merged" my
apm82181 testing 5.10 I broke other targets 5.10 support so bad
that the "fix patch" needed a second "fix patch". :(

And as you have seen even something as simple as a default for
a CONFIG_* SYMBOL can a show-stopper due deer-in-the-headlights
moments from crucial dependencies in different packages like musl...


For example do you really need CONFIG_OABI_COMPAT for gemini?

You should try to remove just most of the options which are not SoC
specific.


Yups I managed to diet out a bunch of stuff.



Do you have an update? I've queued your patch with "one weird trick"
(use KERNEL_TESTING_PATCHVER instead of KERNEL_PATCHVER).


Yes, this will cause the buildbot to still built your target with 5.4
but the 5.10 support will be there (behind CONFIG_TESTING_KERNEL).

Cheers,
Christian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] gemini: Bump to kernel v5.10

2021-04-14 Thread Linus Walleij 
Hi Hauke,

On Tue, Apr 13, 2021 at 11:37 PM Hauke Mehrtens  wrote:

> The target kernel configurations should be small and most of the generic
> settings should be done in the target/linux/generic/config-* config file.
> The target configuration only contains the extra configuration options
> or the options which are different.
(...)
> You can add new generic options to target/linux/generic/config-5.10
> manually.

OK I get it, I sent a slew of patches to the generic config.

We drive-by contributors just assume the generic config is
Perfect(TM) you know, now I realize I have to contribute to that
effort.

> For example do you really need CONFIG_OABI_COMPAT for gemini?
>
> You should try to remove just most of the options which are not SoC
> specific.

Yups I managed to diet out a bunch of stuff.

> To test the new kernel configuration, building with all kernel modules
> activated is helpful. You can do it by activation CONFIG_ALL_KMODS=y in
> the OpenWrt configuration. This is what the build bot uses:
> https://downloads.openwrt.org/snapshots/targets/gemini/generic/config.buildinfo

OK building that now... thanks for all the hints!

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] gemini: Bump to kernel v5.10

2021-04-13 Thread Hauke Mehrtens 

On 4/13/21 10:02 AM, Linus Walleij wrote:

On Mon, Apr 12, 2021 at 8:32 PM Christian Lamparter  wrote:


Hmm, when building this with the BUILDBOT config (CONFIG_BUILDBOT)
and throw in the CONFIG_ALL_* for userspace + kernel modules for
good measure. It fails with the default world build (without the
V=s option) because the following symbols are not yet defined in
either the generic or gemini-specific kernel config.

CONFIG_COMPAT_32BIT_TIME
CONFIG_PCIEASPM
CONFIG_MTD_PHYSMAP_IXP4XX
CONFIG_GPIO_CDEV_V1
CONFIG_CPU_THERMAL
CONFIG_DMA_PERNUMA_CMA

At least CPU_THERMAL is also a show-stopper for apm82181 5.10,
so should these just be added added as either disabled
(# CONFIG_ ... is not set) or in case of CONFIG_PCIEASPM=X
(whatever the default is there) in target/linux/generic/config-5.10?


Hm how do I help best with this? I don't always have the big picture of what
OpenWRT needs, just working in my little corner :D

I get as much as that we need to fix up target/linux/generic/config-5.10
as none of these config options pertain to Gemini per se.

I suppose I should make a separate patch for that setting them all to
"#  is not set" simply.

I am unsure about the procedure to test it though, also I always get a
bit confused about how these configs are even generated.

Yours,
Linus Walleij



Hi Linus,

The target kernel configurations should be small and most of the generic 
settings should be done in the target/linux/generic/config-* config file.
The target configuration only contains the extra configuration options 
or the options which are different.


For example do you really need CONFIG_OABI_COMPAT for gemini?

You should try to remove just most of the options which are not SoC 
specific.


You can add new generic options to target/linux/generic/config-5.10 
manually. For example "# CONFIG_MTD_PHYSMAP_IXP4XX is not set" would 
make sense there, if some target really needs it, the target kernel 
config can be activated for one target again.


You can refresh your kernel configuration like this:
make kernel_oldconfig CONFIG_TARGET=target
and this:
make kernel_oldconfig CONFIG_TARGET=subtarget

To test the new kernel configuration, building with all kernel modules 
activated is helpful. You can do it by activation CONFIG_ALL_KMODS=y in 
the OpenWrt configuration. This is what the build bot uses:

https://downloads.openwrt.org/snapshots/targets/gemini/generic/config.buildinfo

Hauke

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] gemini: Bump to kernel v5.10

2021-04-13 Thread Linus Walleij 
On Mon, Apr 12, 2021 at 8:32 PM Christian Lamparter  wrote:

> Hmm, when building this with the BUILDBOT config (CONFIG_BUILDBOT)
> and throw in the CONFIG_ALL_* for userspace + kernel modules for
> good measure. It fails with the default world build (without the
> V=s option) because the following symbols are not yet defined in
> either the generic or gemini-specific kernel config.
>
> CONFIG_COMPAT_32BIT_TIME
> CONFIG_PCIEASPM
> CONFIG_MTD_PHYSMAP_IXP4XX
> CONFIG_GPIO_CDEV_V1
> CONFIG_CPU_THERMAL
> CONFIG_DMA_PERNUMA_CMA
>
> At least CPU_THERMAL is also a show-stopper for apm82181 5.10,
> so should these just be added added as either disabled
> (# CONFIG_ ... is not set) or in case of CONFIG_PCIEASPM=X
> (whatever the default is there) in target/linux/generic/config-5.10?

Hm how do I help best with this? I don't always have the big picture of what
OpenWRT needs, just working in my little corner :D

I get as much as that we need to fix up target/linux/generic/config-5.10
as none of these config options pertain to Gemini per se.

I suppose I should make a separate patch for that setting them all to
"#  is not set" simply.

I am unsure about the procedure to test it though, also I always get a
bit confused about how these configs are even generated.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] gemini: Bump to kernel v5.10

2021-04-12 Thread Christian Lamparter 

On 12/04/2021 00:11, Linus Walleij wrote:

Only two patches against mainline remains. Switch to v5.10
which works very nicely with all Gemini devices.

Signed-off-by: Linus Walleij 
---
  target/linux/gemini/Makefile  |   2 +-
  target/linux/gemini/config-5.10   | 465 ++
  ...t-fotg2-add-Gemini-specific-handling.patch | 131 +
  ...-DIR-685-partition-table-for-OpenWrt.patch |  37 ++
  4 files changed, 634 insertions(+), 1 deletion(-)
  create mode 100644 target/linux/gemini/config-5.10
  create mode 100644 
target/linux/gemini/patches-5.10/0001-usb-host-fotg2-add-Gemini-specific-handling.patch
  create mode 100644 
target/linux/gemini/patches-5.10/0002-ARM-dts-Augment-DIR-685-partition-table-for-OpenWrt.patch

diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile
index d2acb52facf7..95a5a87eaa4d 100644
--- a/target/linux/gemini/Makefile
+++ b/target/linux/gemini/Makefile
@@ -10,7 +10,7 @@ BOARDNAME:=Cortina Systems CS351x
  FEATURES:=squashfs pci rtc usb dt gpio display ext4 rootfs-part boot-part
  CPU_TYPE:=fa526
  
-KERNEL_PATCHVER:=5.4

+KERNEL_PATCHVER:=5.10


Hmm, when building this with the BUILDBOT config (CONFIG_BUILDBOT)
and throw in the CONFIG_ALL_* for userspace + kernel modules for
good measure. It fails with the default world build (without the
V=s option) because the following symbols are not yet defined in
either the generic or gemini-specific kernel config.

CONFIG_COMPAT_32BIT_TIME
CONFIG_PCIEASPM
CONFIG_MTD_PHYSMAP_IXP4XX
CONFIG_GPIO_CDEV_V1
CONFIG_CPU_THERMAL
CONFIG_DMA_PERNUMA_CMA

At least CPU_THERMAL is also a show-stopper for apm82181 5.10,
so should these just be added added as either disabled
(# CONFIG_ ... is not set) or in case of CONFIG_PCIEASPM=X
(whatever the default is there) in target/linux/generic/config-5.10?

Or CPU_THERMAL could be an issue for some high-powered x86 or ARM?

Cheers,
Christian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] gemini: Bump to kernel v5.10

2021-04-11 Thread Linus Walleij 
Only two patches against mainline remains. Switch to v5.10
which works very nicely with all Gemini devices.

Signed-off-by: Linus Walleij 
---
 target/linux/gemini/Makefile  |   2 +-
 target/linux/gemini/config-5.10   | 465 ++
 ...t-fotg2-add-Gemini-specific-handling.patch | 131 +
 ...-DIR-685-partition-table-for-OpenWrt.patch |  37 ++
 4 files changed, 634 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/gemini/config-5.10
 create mode 100644 
target/linux/gemini/patches-5.10/0001-usb-host-fotg2-add-Gemini-specific-handling.patch
 create mode 100644 
target/linux/gemini/patches-5.10/0002-ARM-dts-Augment-DIR-685-partition-table-for-OpenWrt.patch

diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile
index d2acb52facf7..95a5a87eaa4d 100644
--- a/target/linux/gemini/Makefile
+++ b/target/linux/gemini/Makefile
@@ -10,7 +10,7 @@ BOARDNAME:=Cortina Systems CS351x
 FEATURES:=squashfs pci rtc usb dt gpio display ext4 rootfs-part boot-part
 CPU_TYPE:=fa526
 
-KERNEL_PATCHVER:=5.4
+KERNEL_PATCHVER:=5.10
 
 define Target/Description
Build firmware images for the StorLink/Cortina Gemini CS351x ARM FA526 
CPU
diff --git a/target/linux/gemini/config-5.10 b/target/linux/gemini/config-5.10
new file mode 100644
index ..8208ce698a89
--- /dev/null
+++ b/target/linux/gemini/config-5.10
@@ -0,0 +1,465 @@
+CONFIG_ALIGNMENT_TRAP=y
+CONFIG_AMBA_PL08X=y
+CONFIG_ARCH_CLOCKSOURCE_DATA=y
+CONFIG_ARCH_GEMINI=y
+CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
+CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
+CONFIG_ARCH_HAS_FORTIFY_SOURCE=y
+CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
+CONFIG_ARCH_HAS_KCOV=y
+CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
+CONFIG_ARCH_HAS_PHYS_TO_DMA=y
+CONFIG_ARCH_HAS_RESET_CONTROLLER=y
+CONFIG_ARCH_HAS_SET_MEMORY=y
+CONFIG_ARCH_HAS_SG_CHAIN=y
+CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
+CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
+CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
+CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
+# CONFIG_ARCH_MOXART is not set
+CONFIG_ARCH_MULTIPLATFORM=y
+CONFIG_ARCH_MULTI_V4=y
+# CONFIG_ARCH_MULTI_V4T is not set
+CONFIG_ARCH_MULTI_V4_V5=y
+# CONFIG_ARCH_MULTI_V5 is not set
+CONFIG_ARCH_NR_GPIO=0
+CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y
+CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
+CONFIG_ARCH_SUPPORTS_UPROBES=y
+CONFIG_ARCH_USE_BUILTIN_BSWAP=y
+CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
+CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
+CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
+CONFIG_ARM=y
+CONFIG_ARM_AMBA=y
+CONFIG_ARM_APPENDED_DTB=y
+# CONFIG_ARM_ATAG_DTB_COMPAT is not set
+CONFIG_ARM_HAS_SG_CHAIN=y
+CONFIG_ARM_L1_CACHE_SHIFT=5
+CONFIG_ARM_PATCH_PHYS_VIRT=y
+# CONFIG_ARM_SMMU is not set
+CONFIG_ARM_UNWIND=y
+CONFIG_ATA=y
+CONFIG_ATAGS=y
+CONFIG_ATA_VERBOSE_ERROR=y
+CONFIG_AUTO_ZRELADDR=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_BLK_MQ_PCI=y
+CONFIG_BLK_SCSI_REQUEST=y
+CONFIG_BOUNCE=y
+# CONFIG_BPF_SYSCALL is not set
+CONFIG_CLKDEV_LOOKUP=y
+CONFIG_CLKSRC_MMIO=y
+CONFIG_CLONE_BACKWARDS=y
+CONFIG_CMA=y
+CONFIG_CMA_ALIGNMENT=8
+CONFIG_CMA_AREAS=7
+# CONFIG_CMA_DEBUG is not set
+# CONFIG_CMA_DEBUGFS is not set
+CONFIG_CMA_SIZE_PERCENTAGE=10
+# CONFIG_CMA_SIZE_SEL_MAX is not set
+# CONFIG_CMA_SIZE_SEL_MBYTES is not set
+# CONFIG_CMA_SIZE_SEL_MIN is not set
+CONFIG_CMA_SIZE_SEL_PERCENTAGE=y
+CONFIG_COMMON_CLK=y
+CONFIG_COMMON_CLK_GEMINI=y
+CONFIG_CONSOLE_TRANSLATIONS=y
+CONFIG_COREDUMP=y
+CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
+CONFIG_CPU_32v4=y
+CONFIG_CPU_ABRT_EV4=y
+CONFIG_CPU_CACHE_FA=y
+CONFIG_CPU_CACHE_VIVT=y
+CONFIG_CPU_COPY_FA=y
+CONFIG_CPU_CP15=y
+CONFIG_CPU_CP15_MMU=y
+# CONFIG_CPU_DCACHE_WRITETHROUGH is not set
+CONFIG_CPU_FA526=y
+CONFIG_CPU_NO_EFFICIENT_FFS=y
+CONFIG_CPU_PABRT_LEGACY=y
+CONFIG_CPU_TLB_FA=y
+CONFIG_CPU_USE_DOMAINS=y
+CONFIG_CRASH_CORE=y
+CONFIG_CRC16=y
+# CONFIG_CRC32_SARWATE is not set
+CONFIG_CRC32_SLICEBY8=y
+CONFIG_CRC_CCITT=y
+CONFIG_CRC_ITU_T=y
+CONFIG_CROSS_MEMORY_ATTACH=y
+CONFIG_CRYPTO_AEAD=y
+CONFIG_CRYPTO_AEAD2=y
+CONFIG_CRYPTO_CCM=y
+CONFIG_CRYPTO_CMAC=y
+CONFIG_CRYPTO_CRC32C=y
+CONFIG_CRYPTO_CTR=y
+CONFIG_CRYPTO_DES=y
+CONFIG_CRYPTO_DRBG=y
+CONFIG_CRYPTO_DRBG_HMAC=y
+CONFIG_CRYPTO_DRBG_MENU=y
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_ECHAINIV=y
+CONFIG_CRYPTO_GCM=y
+CONFIG_CRYPTO_GF128MUL=y
+CONFIG_CRYPTO_GHASH=y
+CONFIG_CRYPTO_HASH=y
+CONFIG_CRYPTO_HASH2=y
+CONFIG_CRYPTO_HMAC=y
+CONFIG_CRYPTO_HW=y
+CONFIG_CRYPTO_JITTERENTROPY=y
+CONFIG_CRYPTO_MANAGER=y
+CONFIG_CRYPTO_MANAGER2=y
+CONFIG_CRYPTO_MD4=y
+CONFIG_CRYPTO_MD5=y
+CONFIG_CRYPTO_NULL=y
+CONFIG_CRYPTO_NULL2=y
+CONFIG_CRYPTO_RNG=y
+CONFIG_CRYPTO_RNG2=y
+CONFIG_CRYPTO_RNG_DEFAULT=y
+CONFIG_CRYPTO_SEQIV=y
+CONFIG_CRYPTO_SHA256=y
+CONFIG_CRYPTO_WORKQUEUE=y
+CONFIG_DEBUG_BUGVERBOSE=y
+CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
+CONFIG_DEBUG_MEMORY_INIT=y
+CONFIG_DECOMPRESS_BZIP2=y
+CONFIG_DECOMPRESS_GZIP=y
+CONFIG_DECOMPRESS_LZ4=y
+CONFIG_DECOMPRESS_LZMA=y
+CONFIG_DECOMPRESS_LZO=y
+CONFIG_DECOMPRESS_XZ=y
+CONFIG_DEFAULT_CFQ=y
+# CONFIG_DEFAULT_DEADLINE is not set
+CONFIG_DEFAULT_IOSCHED="cfq"
+CONFIG_DMADEVICES=y