In the kernel configuration, check if the following are enabled:
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_M25P80=y
CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_SPLIT_FIRMWARE=y
CONFIG_MTD_SPLIT_SUPPORT=y
CONFIG_MTD_SPLIT_FIT_FW=y
CONFIG_MTD_SPLIT_UIMAGE_FW=y
CONFIG_MTD_OF_PARTS=y
I have nothing with this processor, but look somewhere in: /target/linux/realtek/rtl8xxx/config-5.10
Hi
Thanks a lot for your input, after applying the above changes in "https://github.com/ggbruno/openwrt"(kernel 4.14), this works fine, I could see the komikan board is booting. However when I try the code which is cloned from your repository ( kernel 5.4 ). The link is here "https://github.com/zafar1384/komikan_5.4". In this case I am getting the following error:
Starting kernel at 80000000...
[ 0.000000] Linux version 5.4.52 (user@ubuntu) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r14042-58c33c4569)) #0 PREEMPT Wed Mar 10 13:47:47 2021
[ 0.000000] printk: bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 00019385 (MIPS 24Kc)
[ 0.000000] MIPS: machine is Multilaser RE708 V1
[ 0.000000] Initrd not found or empty - disabling initrd
[ 0.000000] BOOTSTRAP = 8197f001 0 412582e0 80000000
[ 0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[ 0.000000] Primary data cache 32kB, 4-way, PIPT, no aliases, linesize 32 bytes
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000000000000-0x0000000003ffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x0000000003ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000003ffffff]
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16240
[ 0.000000] Kernel command line: console=ttyS0,38400
[ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[ 0.000000] Writing ErrCtl register=0000e0a7
[ 0.000000] Readback ErrCtl register=0000e0a7
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 57364K/65536K available (4882K kernel code, 174K rwdata, 1032K rodata, 1200K init, 196K bss, 8172K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] NR_IRQS: 128
[ 0.000000] random: get_random_bytes called from start_kernel+0x338/0x52c with crng_init=0
[ 0.000000] timer_probe: no matching timers found
[ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 3822520893 ns
[ 0.000007] sched_clock: 32 bits at 500MHz, resolution 2ns, wraps every 4294967295ns
[ 0.008545] Calibrating delay loop... 663.55 BogoMIPS (lpj=1327104)
[ 0.047269] pid_max: default: 32768 minimum: 301
[ 0.052457] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.060375] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.070834] rcu: Hierarchical SRCU implementation.
[ 0.077828] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.088685] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[ 0.097055] NET: Registered protocol family 16
[ 0.141242] clocksource: Switched to clocksource MIPS
[ 0.152058] NET: Registered protocol family 2
[ 0.158813] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 0.168142] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.176628] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.184316] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.191422] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 0.198609] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 0.206500] NET: Registered protocol family 1
[ 0.211266] PCI: CLS 0 bytes, default 32
[ 0.216509] 1800351c.gpio-controller: Realtek GPIO controller driver
[ 0.226405] workingset: timestamp_bits=14 max_order=14 bucket_order=0
[ 0.259052] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 0.265786] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[ 0.279481] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[ 0.290721] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled
[ 0.299759] printk: console [ttyS0] disabled
[ 0.305105] 18147000.serial: ttyS0 at MMIO 0x18147000 (irq = 17, base_baud = 6250000) is a 16550A
£[ 0.315021] printk: console [ttyS0] enabled
[ 0.315021] printk: console [ttyS0] enabled
[ 0.323416] printk: bootconsole [early0] disabled
[ 0.323416] printk: bootconsole [early0] disabled
[ 0.334856] slram: not enough parameters.
[ 0.340005] spi-nor spi0.0: change speed to 41000000Hz, div 3
[ 0.346139] spi-nor spi0.0: found w25q256, expected m25p80
[ 0.351746] INFO: flash mode error, cmd 0x5A, flash_mode 0
please suggest what is wrong here,
thank you,
Regards,
Zafar
I didn't change the sheipa spi driver, perhaps a problem in frequency, try to reduce her to 40000000Hz in your dts file
spi-max-frequency = <40000000>;
Hi, reducing frequency also did not work, I tried till 20Mhz
[ 0.329071] printk: console [ttyS0] enabled
[ 0.337550] printk: bootconsole [early0] disabled
[ 0.337550] printk: bootconsole [early0] disabled
[ 0.348923] slram: not enough parameters.
[ 0.354085] spi-nor spi0.0: change speed to 20000000Hz, div 5
[ 0.359808] DO SPI COMMAND
[ 0.362946] DO SPI COMMAND
[ 0.365643] INFO: flash mode error, cmd 0x5A, flash_mode 0
Since the kernel is changed from 4.14 to 5.4 do we need to do modification in driver
Hi, I have a router (Tenda AC5) with the Chip RTL8197FN, it is different from the RTL8197F built-in Switch. Ram 64 MB, rom 8 MB. I can help you help in testing, and is there already builds for such routers?
@gaspare
I noticed there is no support for RTL8198C in new kernel , I think it is looks like RTL8197F , I just wondering why it is missed in the great source code you developed.
thanks
Hi guys,
there is another very cheap device with "seamless roaming" support on OEM in the market below 20€ (Offer -67%), but the OEM-firmware sucks a lot. You can just use ist as an closed subnet in your network. That doesn't make much sense. - Telnet is enabled, but no easy login with "admin/admin" or "root/root" and so on.
It is called Meross MMW120 and contains:
RTL8363NB
RTL8197FS
RTL8812F
Winbond 25Q128JVSQ
I add some pictures. - For me it sounds very interesting with "Seamless roaming".
Anyone inrested in developing Owrt for it?
RTL8363 is a 2 port giga switch... It is the same as RTL8366/7 found in the other realtek routers, with less ports...
https://www.realtek.com/en/products/communications-network-ics/item/rtl8363nb-vb-cg
Hey @gaspare I read your also trying to develop Owrt for these kind of devices. - Have you been successful so far and how could we start with these device? - Does a Serial log file help or have we already some kind of example images to just adjust a bit?
I started some initial work for RTL8198C. Being a native MIPS big endian SoC the realtek tree will be the favourite place for inclusion.
Hey guys, did this thread end up going very far? It seems like the guys in this thread (and predecessors) already made an amazing amount of progress and it seems that some chip drivers were integrated in the kernel.
Out of curiosity, I was just looking at a whole lot of Tenda stuff on fccid.io as they seem to be quite cheap and available in places like the US, Australia, China, and also India.
I noticed that the Tenda RX2 Pro (AX1500) has several of the chips that are mentioned in this thread, RTL8197H (not F, but shouldn't be too different), the RTL8367RB and only the RTL8832BS is not mentioned in this thread. The FCC has a bunch of pictures of the chips here - https://fccid.io/V7TRX2P/Internal-Photos/Internal-Photos-6103617
It seems that there are a bunch of other Tenda brand AX routers that may be very close to being supported if these chips could be supported. Of all the FCC stuff I looked at, Tenda seem to use Realtek or Broadcom, and I had written them off, but then I found this thread about Realtek SOCs.
I don't have any of this hardware AFAIK (except the 2.5G PHY in my Netgear WAX206), but it just seems to me that this could open up a whole new area of development for OpenWRT and potentially for areas that don't have easy access to more mainstream brands that OpenWRT currently supports.
See also the following, for example;
Tenda RX2 AX1500 internals - similar to RX2 Pro with 8367RB, 8832BS, 8197H
Tenda A23 AX1500 internals (8197H, 8832BR, 8211F)
Tenda HG15 AX1500 internals - 8192F, 8832BR, 9607C
Any thoughts? 
Run for the hills and get a devices that's actually supported, now. There are plenty of options, but Realtek is not among them.
OK, understood. Just a shame that so much was achieved and it doesn't seem to have gotten very far, and there's potential here for third world among other things.
Realtek are lazy.
Why bother adding your hw to the Linux kernel, if you don't have to ?
Vote with your wallet, and stay away.
No one prevents you from picking up the development, but after you have done the work on the SOC- and toolchain (gcc, binutils, musl) side, you'd be still left with the sorry state of Realtek wireless drivers for Linux.
If you're looking for a timeframe less than years-at-best-but-more-likely-never, there are options that work right now.
OK, sorry to open a can of worms 
I agree with your stance regarding the Realtek Wireless HW/SOCs, and also do now want to 'reward' their behavior, but when it comes to Managed POE-Switches with Openwrt-support (and POE-Powermonitoring/-switching), they seem to be the only viable/available option right now (unfortunately).
I'll be honest here. This all started for me today from a few things:
I keep seeing people asking can we support this router and that router, and I understand and fully support why there are many routers that are currently not supported and that the chip manufacturers play a large part in that. I was thinking the forum should have a sticky post with a long list of routers that are unlikely to be supported, and the reasons why, partly to stem the questions. I still strongly think that is a good idea. Perhaps it could even be part of some sort of PR push?
The first point came to mind as I googled ax routers and found a bunch that seemed a step cheaper than the netgear wax202 that I think is currently one of the best OpenWRT options in this space for its price, at least in my part of the world (Australia). I noticed that prominent among the slightly cheaper AX routers brands here is Tenda, and I started ruling out models one by one because of the chipsets that I could see on the FCC site showing either Broadcom or Realtek. I then thought of the idea in point 1.
I realised that there is at least some support for Realtek, even if minor, because I know my Netgear Wax206 has a Realtek PHY for the ethernet 2.5Gb WAN port. When I searched I found this thread and at first I thought it was just confirming what I thought was the OpenWRT/Realtek story, but then it seems that some amazing people made a lot of amazing progress, only to get stuck at a certain point. Amazing people were still active on this topic over 2.5 years until late last year. I was inspired by this and wondered why it stopped when such great progress had been made by these amazing people.
In my googling, I realised that not only are brand like Tenda with their Realtek chips slightly cheaper in the west, but I kept seeing stuff about India and other third world countries. Perhaps some of this amazing work that is so close to bearing real fruit could also be a real win not just for a stingy westerner such as myself, but for a whole group of people who currently don't seem greatly represented by or within OpenWRT. Perhaps it might even stimulate people (who are not westerners) to jump on board because they could be a pay off for them with hardware that is available to them at a reasonable price?
I fully agree that open source unfriendly manufacturers should not be rewarded. I just saw a possibility of a coming together of a bunch of things in a way that might lead to something good. Sometimes things like this can happen for the general good in spite of the companies and the economics and the politics. I mean who ever saw Rick Rolling relaunching a pop star's dead career?
No, am not a programmer and no I don't know all the nuances of the toolchains etc, but I saw something really positive in this thread. I wish I could personally run with this a bit more. I meant no disrespect to the community and the current and previous devs and I certainly did not want to appear demanding, only amazed and encouraged by this thread. I deeply respect the devs that have brought and keep bringing us OpenWRT, and I deeply respect the blood sweat and tears that the people involved in the amazing story of this thread alone have put into something that almost got there for the greater good.
Peace and thanks.
I would not exactly call Realtek "opensource unfriendly[0]", they tend to meet the license requirements. But -until recently- that didn't imply contributing their SOC/ (USB in particular-) wireless support upstream, but merely throwing a(n opensource) vendor driver over the fence and immediately forgetting about it and doing the same for the next hardware generation. Legally meeting the requirements, but neither helping their users, nor themselves.
But with Realtek, we were long plagued by their use of the lexra ISA (patent mine field, 'thanks' to Imagination Technologies, and zero linux/ libc/ toolchain support), the wireless vendor drivers (~2.6.13 era ieee80211softmac forks) without nl80211 support (and custom hostapd interfaces/ ancient forks) and typically very low-end hardware (SOC speed, flash, RAM). The combination of all these makes it very hard to work on it - and the low-end hardware successfully prevents anyone serious to want buying these devices.
Realtek having moved away from lexra to full mips (or ARM) and starting to care more about mainline contributions (e.g. rtw88/ rtw89) is promising, but after them being a non-option for one-and-a-half decade, they are far behind in gaining volunteer cooperation. Being cheap and plenty does not (always) offset unusable (but technically available) driver support and usually very low-end specs (volunteer developers are more willing to move away obstacles for new/ high-end/ challenging hardware that will remain relevant for longer).
From an enduser's perspective none of this really matters - the facts just are, these SOCs currently aren't supported, there is no one actively working on them either - and all realistic expectations imply that they never will be. From time to time miracles may happen (e.g. rtl838x/ rtl93xx), but betting on them before they are actually materializing as pre-merge PRs would be 'misguided' and a game prone to lose.
If you're looking to actually use your devices during their prospected life span, look at already fully supported ones only.
--
[0] that would be more fitting for Broadcom-, NXP- or Maxlinear wireless.
