SWRT-dev
GRX350/500 in-kernel support
hi,
i saw this repository in my perusal of sources that support the GRX350/550 processors.
does this kernel work for the dual core intel interaptiv mips devices?
if so, i'm very intrigued and want to determine if i can merge the changes from the GPL into 4.14 for my own build.
Intel’s sdk supports two kernels, 3.10 and 4.9, and does not support 4.14. If you want to get more information about the 4.9 kernel, you can see https://gitlab.com/prpl-foundation/intel/linux/-/tree/ugw_8.4.2
What's up paldier.
This is exciting stuff. I'll get back to you on a few things.
I want to mention that when I put the drivers/net dir in my own buldroot, it whined about LOGGER issues.
admittedly, when I cloned your git and tried to build, I got errors that seemed to reflect differences between 4.14 and 4.9.
someone as schooled as you could comment as to whether the existing code can be ported to 4.14?
I'm trying to consolidate mips targets.
From: paldier Sent: Friday, 2 April 2021 6:15 PM To: MerlinRdev/bluecave-merlin Reply To: MerlinRdev/bluecave-merlin Cc: gagan sidhu; Author Subject: Re: [MerlinRdev/bluecave-merlin] GRX350/500 in-kernel support (#21)
Intel’s sdk supports two kernels, 3.10 and 4.9, and does not support 4.14. If you want to get more information about the 4.9 kernel, you can see https://gitlab.com/prpl-foundation/intel/linux/-/tree/intel-4.9.218
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/MerlinRdev/bluecave-merlin/issues/21#issuecomment-812762207, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AITLEG7SXOJ3GK4PJTSICQLTGZMZ7ANCNFSM42JIODIA.
greetings you beautiful man @paldier.
i can confirm i have succesfully loaded mtlkroot using your built root built against my DD-WRT 4.14 :
Apr 2 19:41:37 DD-WRT user.info kernel: Loading modules backported from Linux version v5.1-e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd
Apr 2 19:41:37 DD-WRT user.info kernel: Backport generated by backports.git v3.10.104
Apr 2 19:41:37 DD-WRT user.warn kernel: [MTLKD] Allocated netdev rtlog0 addr 8395c000
Apr 2 19:41:42 DD-WRT user.warn kernel: [MTLKD] Netlink module cleanup done
Apr 2 19:41:42 DD-WRT user.warn kernel: [MTLKD] Unloading rtlog_netdev
what i found interesting is that it would not load against my v5.10.16-1 backports
[92073.497172] Loading modules backported from Linux version wireless-drivers-next-2021-02-12-0-g9d083348e938
[92073.497186] Backport generated by backports.git v5.10.16-1-0-g21d2a1d2
[92073.505179] [MTLKD] Allocated netdev rtlog0 addr 85a5f800
[92073.505253] [MTLKD] Failed to register Netlink family: res=-22
[92073.505282] [MTLKD] Unloading rtlog_netdev
the only concern i have with the porting is the warning:
warning: ignoring attribute ‘packed’ because it conflicts with attribute ‘aligned’
Uwe spoke about it here and i'm not sure if i should be too worried.
does this look promising enough for me to grab this clearance RAX40? my only other reservation is about the actual arch/mips/lantiq code for the GRX500 (which is what i presumably enable for the RAX40) not compiling cleanly.
given this driver compiled relatively cleanly, should i be concerned?
RAX40 is the netgear AX4 (see here https://wikidevi.wi-cat.ru/Netgear_RAX40_(Nighthawk_AX4))
i've never used PRPLWRT but from what i can see that is a different group of users.
i'm trying to bring this platform to the mainstream.
i'm not a part of openwrt or dd-wrt. both of their leaders do not like me because i criticise their choices and call them stupid.
i am curious to see if i can patch 4.14 using the prplfoundation 4.9 patches.
i don't know why openwrt abandoned any lantiq support. i was surprised to see they even had patches for 4.9.
their mt76 driver for the mt7615 driver is extremely poor, but they continue to plug their ears whilst making loud noises to drown out any criticisms. it seems this is how things operate with certain groups.
There are some lantiq developers in the prplwrt, so joining the prplwrt is the best choice.
I will be perusing the sources in the next few days. I'm happy I got this driver to build. Now I have to see if the changes to mips CPS/etc between 4.9 and 4.14 are tolerated by the existing grx500 arch/mips/lantiq code
From: paldier Sent: Friday, 2 April 2021 8:39 PM To: MerlinRdev/bluecave-merlin Reply To: MerlinRdev/bluecave-merlin Cc: gagan sidhu; Author Subject: Re: [MerlinRdev/bluecave-merlin] GRX350/500 in-kernel support (#21)
There are some lantiq developers in the prplwrt, so joining the prplwrt is the best choice.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/MerlinRdev/bluecave-merlin/issues/21#issuecomment-812784795, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AITLEGYRO4V6SFUBAXHU5VTTGZ5XXANCNFSM42JIODIA.
what's up @paldier so now that i have full support for popular D-LINK devices, i'm looking at this stuff again.
i have a question for you man, which 4.9 patches are important?
i saw this list of patches: https://github.com/paldier/prplwrt/tree/master/target/linux/lantiq/patches-4.14
but i also remember seeing one directory called "patches-4.9" that had over 100 patches. some of them were hotfixes to the drivers: (edit found it!!): https://github.com/prplfoundation/feed-intel/tree/intel-19.07/intel_mips/patches-4.9
i want to be sure i'm using the latest and up-to-date patches.
hello brother @paldier. i applied all the patches, lol.
my question for you is what a good configuration file would be.
https://github.com/paldier/feed_target_mips/blob/ugw-8.4.2-cleanup/xrx500_4kec/config-default
seems very minimal. i wanna know what ehternet driver, spi , etc i should be configuring.
let's say i want to try this with TP-LINK AX50
should i use this as a template? :
https://github.com/paldier/feed_target_mips/blob/ugw-8.4.2-cleanup/xrx500/config-default
also, in terms of kernel configuration, can we consider PXB4385/PXB4395/GRX350 as equivalent?
There are 6 versions of grx350, only one is not discontinued, npu is automatically configured by firmware, so it's no different to you.
so CONFIG_SOC_GRX500 covers all of the existing SoCs (which are "GRX350" i assume)?
grx500 includes all grx350 and grx550(except the first version). In fact, it’s just that their clock speeds are different.
thanks man.
is iwlwav only for WAV654? or will it work for all 6 versions of the grx350?
edit: i'm so fucking excited paldier. COHERENT DMA. like, i know this thing is going to haul fucking ass dude.
i feel bad for you because it seems very difficult to maintain this platform, and it seems the entire open source effort has fallen on your shoulders. you should be lauded for being composed for this long. it's an impossible task.
i've seen all the complaints about this platform and it just amazes me people even have it running on 3.10, let alone manufacturers distributing it.
iwlwav only supports wav600 now, the support for wav500 has not been completed, it looks like it won't be finished. The performance of the 3.x kernel is the best(non hardware nat). The performance of the 4.x kernel is only equivalent to 60%-80% of the 3.x kernel
was wav500 support close to being finished?
maybe your 3.x kernel builds are good, but a lot of the noobs who bought this SoC off the shelf are complaining about multiple reboots etc.
personally i have higher hopes for my build. i know for my RALINK 4.x build it's pretty close to padavan, but i can't fully test since i don't have a 160MHz client.
you say no hardware nat acceleration for 3.x. i assume hardware nat kernel is even more difficult to build?
iwlwav is an open source driver in 4.x kernel, the closed source driver supports wav500 and wav600 in the 3.x kernel.
so you mean i have to sign an NDA to get the closed source driver? no hope of an update to 4.x?
hopefully iwlwav performance on 3.x isn't bad, if you're able to backport it? just curious about its performance.
@paldier i assume HW acceleration is from CONFIG_PPA.
CONFIG_PPA_API_DIRECTPATH=y
# CONFIG_PPA_API_DIRECTCONNECT is not set
CONFIG_PPA_API_SW_FASTPATH=y
CONFIG_PPA_TCP_LITEPATH=y
CONFIG_PPA_TMU_MIB_SUPPORT=y
# CONFIG_PPA_BR_MAC_LEARNING is not set
CONFIG_PPA_RT_SESS_LEARNING=y
# CONFIG_PPA_BR_SESS_LEARNING is not set
# CONFIG_PPA_MPE_IP97 is not set
are these defaults appropriate for all platforms? 4.9 builds no problem with it enabled ^_^ very excited lol
@paldier what DTS do i use? will easywan_350.dts work for the AX50?
i'm so pumped. tomorrow (~16 hours) is testing day.
this thing is going to haul ass brother, i "believe"!!!
@paldier it's so weird flashing this thing. any tips?
the unaffiliated individual who acquired this device noticed that the bootloader menu is not typical, and is perplexed as to how to try a different image.
they're used to the typical operation of creating a uImage from mkimage, then appending the ubinized squashfs, followed by selecting 'write to flash from TFTP' in u-boot.
in comparison, this bootloader seems very different.
they are excited, but confused!
using this as a template: https://github.com/nirmitg/openwrt/blob/5f915c2dc4bea3d682972ce8471599d0ea1a900c/ugw/target/linux/lantiq/image/Makefile.openwrt
i know you don't support AX50 but i thought you'd have some ideas. i didn't know they'd be this different. tp-link's upgrade image seems like a nightmare:
GagansMacPro:router Gagan$ binwalk ~/Downloads/Archer\ AX50\(US\)_V1_200708/ax50v1_intel-up-ver1-0-9-P1\[20200708-rel55037\]_signed.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
4519 0x11A7 uImage header, header size: 64 bytes, header CRC: 0xB7455DE6, created: 2020-07-08 07:18:29, image size: 29654552 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0x506ACDE2, OS: Linux, CPU: MIPS, image type: Multi-File Image, compression type: none, image name: "TP-Link Totalimage"
4591 0x11EF uImage header, header size: 64 bytes, header CRC: 0xF85FFD41, created: 2020-07-08 07:18:28, image size: 150864 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0x888C4C94, OS: Linux, CPU: MIPS, compression type: lzma, image name: "U-Boot Img"
39107 0x98C3 CRC32 polynomial table, little endian
51855 0xCA8F CRC32 polynomial table, little endian
55855 0xDA2F uImage header, header size: 64 bytes, header CRC: 0x908FBBD4, created: 2020-07-08 05:01:29, image size: 99600 bytes, Data Address: 0xA0400000, Entry Point: 0xA0400000, data CRC: 0x38F8E3FA, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: lzma, image name: "u-boot image"
55919 0xDA6F LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 343580 bytes
155519 0x25F7F uImage header, header size: 64 bytes, header CRC: 0xCD4DD048, created: 2020-07-08 07:18:29, image size: 131072 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0x6C65B573, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: lzma, image name: "gphyfw"
155583 0x25FBF uImage header, header size: 64 bytes, header CRC: 0xE76A1040, created: 2020-07-08 05:01:39, image size: 29176 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0x6D88B827, OS: Linux, CPU: MIPS, image type: Multi-File Image, compression type: lzma, image name: "GPHY Firmware"
155655 0x26007 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 65664 bytes
286655 0x45FBF uImage header, header size: 64 bytes, header CRC: 0x846655C1, created: 2020-07-08 07:17:38, image size: 26226688 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0x78134F7C, OS: Linux, CPU: MIPS, image type: Filesystem Image, compression type: lzma, image name: "LTQCPE RootFS"
286719 0x45FFF Squashfs filesystem, little endian, version 4.0, compression:xz, size: 26223172 bytes, 5462 inodes, blocksize: 131072 bytes, created: 2020-07-08 07:17:37
26513407 0x1948FFF uImage header, header size: 64 bytes, header CRC: 0xC71E56C7, created: 2020-07-08 05:17:29, image size: 3145664 bytes, Data Address: 0xA0020000, Entry Point: 0xA002DF00, data CRC: 0xD79B6C75, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS LTQCPE Linux-3.10.104"
26513471 0x194903F LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 9232128 bytes
@paldier hello? lol. it seems i need to figure out where to get u-boot images.
it must be as simple as including firmware and rootfs with u-boot images. could you please point me in the right direction? you have to know.
https://github.com/MerlinRdev/bluecave-merlin/tree/master/release/src-lantiq/proprietary
seems to have the gphy images, but bluecave seems slightly different.
will read this makefile more closely: https://github.com/MerlinRdev/bluecave-merlin/blob/master/release/src-rt/Makefile
@paldier can you tell me anything about the u-boot ddr3 timings file?
i'm using EVA and i need to use a newer version of the intel u-boot. but i don't have tp-link's DDR3 timings file (missing in GPL). but from what i gather, the u-boot configuration files should be there?
ok.
i assume i can't use xrx500_phy_fw from @blogic/@openwrt, and i must use ethernet driver's gphy-fw loader?
and i assume the firmware in https://github.com/paldier/ltq_fw_phy_ip/xRx5xx should work right?
lol switch_api is fucking HUGE man. 500K lol wtf!
@paldier bro i'm getting so jacked hooking iwlwav-hostap into the DD-WRT build tree. enabling 80211AX and ACS, settings that he has never used for his builds.
this thing better haul ass man!!
@paldier do you know if it's possible to use the iwlwav-dev backports driver with a newer backports? i'm wondering if the iwlwav-dev using backports-3.10 (instead of 4.9, which is what i'm using) may optimise performance.
i know you said intel tested on a 4.9 kernel, but i haven't tried to update the backports since the tree builds with the 4.9 target kernel easily. i didn't realise until now it's using backports 3.10