From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from helium.openadk.org (helium.openadk.org [89.238.66.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3839435C1AC for ; Thu, 5 Feb 2026 07:29:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=89.238.66.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770276578; cv=none; b=OEL9FflWNV4E1PlkFMqwgUtUuzYN7sb/+O/YiCUU1WLUX7aItcbnLnbvcfcjI9dGV+GXm2Rh6UINpdUhjndnppUQs74hkEeWvhSpTPHrTSr9NAUB9epnUwXvAKL9jHRKVCadIzFUwb7EAsQ/A+6kRhIxb2L5m3hhJ7vC8ifK+dU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770276578; c=relaxed/simple; bh=bnfRDuh5TxdeRBerCjCax/Fy2/YvXgK0kqjWZX3oBK8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FbYwHoi3eGSHlV1chReBInQMrlb+e9qpcuoiEPXfzVj9X4syr8IOZFACEgLAqWmFyjTLk0QatfoMC2MqZlSoWpb3c+QdQuj4iZlibHjTzHGJ+4KILRTsBeywfnr+72cJjDh0PytQyFwxa8Tg/2M4kDi1CkYFVKRrtKrARbdkTt4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=openadk.org; spf=pass smtp.mailfrom=openadk.org; dkim=fail (0-bit key) header.d=openadk.org header.i=@openadk.org header.b=m37OwDw6 reason="key not found in DNS"; arc=none smtp.client-ip=89.238.66.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=openadk.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=openadk.org Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=openadk.org header.i=@openadk.org header.b="m37OwDw6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=openadk.org; s=2022; t=1770276570; bh=bnfRDuh5TxdeRBerCjCax/Fy2/YvXgK0kqjWZX3oBK8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m37OwDw6idA9O+AX+u2ra+JkXXJEeQ4JQlRoSzMTTdI7e/W8eO4xsGJSHfoz9lzeQ prAZojp79c1mPzpqdvllRDbOVDuHpHGqtE03Cyoq6EeiHDY1Hrgs6BkuzNj3u1/WJs c401aa+ssPdDzHwGvodagxIPazBcazCj/9c9Zl5bOU2tyynV3HRyrAo/pcIrLqxmu/ mjkkzRIH4vtTBGJg7LpT/QM6nvHJTjMzS1FDEnL5fLM0X/qsyMJPA86ZweoPtz7Qwu jGxqOmMlpFHLjuFZdG/sDebE70NQqX1vGkTQqAbwZUUBYsYbd424Qf/Jw6f8x4w2z2 Rxa6TjCWhMN8Q== Received: by helium.openadk.org (Postfix, from userid 1000) id 6A10A31E0BA1; Thu, 05 Feb 2026 08:29:30 +0100 (CET) Date: Thu, 5 Feb 2026 08:29:30 +0100 From: Waldemar Brodkorb To: Rong Zhang Cc: Waldemar Brodkorb , Jonas Gorski , Jiaxun Yang , "linux-mips@vger.kernel.org" , Rong Zhang Subject: Re: serial console on Mikrotik RB532 non-working Message-ID: References: <1e9086c1-0cec-4aa7-aab6-e1e605dd9ebf@app.fastmail.com> Precedence: bulk X-Mailing-List: linux-mips@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Linux 6.12.63+deb13-amd64 x86_64 Hi Rong, Rong Zhang wrote, > Hi Waldemar, > > On Wed, 2026-02-04 at 17:38 +0100, Waldemar Brodkorb wrote: > > Hi Mips people, > > Jonas Gorski wrote, > > > > > On Wed, Feb 4, 2026 at 12:19 PM Waldemar Brodkorb wrote: > > > > > > > > Hi Jonas, > > > > Jonas Gorski wrote, > > > > > > > > > Hi, > > > > > > > > > > On Tue, Feb 3, 2026 at 7:25 PM Waldemar Brodkorb wrote: > > > > > > > > > > > > Hi Jiaxun, > > > > > > Jiaxun Yang wrote, > > > > > > > > > > > > > > On Tue, 3 Feb 2026, at 3:24 PM, Jiaxun Yang wrote: > > > > > > > > On Sun, 1 Feb 2026, at 6:39 PM, Waldemar Brodkorb wrote: > > > > > > > > > Hi MIPS hackers, > > > > > > > > > > > > > > > > > > I want to use the latest Linux kernel on my Mikrotik RB532, but the > > > > > > > > > serial console is non working. I bisected the problem and the first > > > > > > > > > breaking change is this commit: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Can you try this? > > > > > > > > > > > > > > Oops sorry I missed a flag, it should be: > > > > > > > > > > > > > > diff --git a/arch/mips/rb532/devices.c b/arch/mips/rb532/devices.c > > > > > > > index 8ecb56be81ac..239018540221 100644 > > > > > > > --- a/arch/mips/rb532/devices.c > > > > > > > +++ b/arch/mips/rb532/devices.c > > > > > > > @@ -213,11 +213,12 @@ static struct platform_device rb532_wdt = { > > > > > > > static struct plat_serial8250_port rb532_uart_res[] = { > > > > > > > { > > > > > > > .type = PORT_16550A, > > > > > > > - .membase = (char *)KSEG1ADDR(REGBASE + UART0BASE), > > > > > > > + .mapbase = REGBASE + UART0BASE, > > > > > > > + .mapsize = SZ_4K, > > > > > > > .irq = UART0_IRQ, > > > > > > > .regshift = 2, > > > > > > > .iotype = UPIO_MEM, > > > > > > > - .flags = UPF_BOOT_AUTOCONF, > > > > > > > + .flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP, > > > > > > > }, > > > > > > > { > > > > > > > .flags = 0, > > > > > > > > > > > > > > > > > > > I tried the patch, but it still hangs here: > > > > > > > > > > > > RouterBOOT booter 2.18 > > > > > > > > > > > > RouterBoard 532 > > > > > > > > > > > > CPU frequency: 399 MHz > > > > > > Memory size: 32 MB > > > > > > > > > > > > Press any key within 3 seconds to enter setup... > > > > > > trying dhcp protocol... OK > > > > > > resolved mac address 9C:BF:0D:00:D6:4E > > > > > > Gateway: 192.168.1.254 > > > > > > transfer started ........................................ transfer ok, time=525.70s > > > > > > setting up elf image... OK > > > > > > jumping to kernel code > > > > > > > > > > > > Nothing in tcpdump tries to mount nfs, so I believe serial console > > > > > > breakage is not the only problem here. > > > > > > > > > > Have you tried the patch on top of master or > > > > > 6e690d54cfa802f939cefbd2fa2c91bd0b8bd1b6? > > > > > > > > > > If it works on top of 6e690d54cfa802f939cefbd2fa2c91bd0b8bd1b6, then > > > > > it fixes the serial issue, and you can do a new git bisect between > > > > > 6e690d54cfa802f939cefbd2fa2c91bd0b8bd1b6 and master to find the next > > > > > breakage, with the patch re-applied on top each step (so serial stays > > > > > working). > > > > > > > > Yes, thanks for the idea. I already had this idea in mind and I am 9 > > > > steps before I get the next breakage :) > > > > > > > > Thanks for the heads up, > > > > > > Also a small warning when doing a bisect with git am'd patches on top: > > > always (git) reset to the original tested commit before doing git > > > bisect , else git bisect will account for these commits on > > > top in calculating the next revision to test and may suggest the very > > > same commit again you were originally testing. > > > > > > It took a me a few steps until I noticed I was running in circles when > > > I had to bisect with a few patches on top. > > > > I just used patch and git stash for the job :) > > So here is the result, the failing commit is: > > commit 9f048fa487409e364cf866c957cf0b0d782ca5a3 (HEAD) > > Author: Maciej W. Rozycki > > Date: Thu Nov 13 05:21:10 2025 +0000 > > > > MIPS: mm: Prevent a TLB shutdown on initial uniquification > > > > Depending on the particular CPU implementation a TLB shutdown may occur > > if multiple matching entries are detected upon the execution of a TLBP > > or the TLBWI/TLBWR instructions. Given that we don't know what entries > > we have been handed we need to be very careful with the initial TLB > > setup and avoid all these instructions. > > > > Therefore read all the TLB entries one by one with the TLBR instruction, > > bypassing the content addressing logic, and truncate any large pages in > > place so as to avoid a case in the second step where an incoming entry > > for a large page at a lower address overlaps with a replacement entry > > chosen at another index. Then preinitialize the TLB using addresses > > outside our usual unique range and avoiding clashes with any entries > > received, before making the usual call to local_flush_tlb_all(). > > > > This fixes (at least) R4x00 cores if TLBP hits multiple matching TLB > > entries (SGI IP22 PROM for examples sets up all TLBs to the same virtual > > address). > > > > Signed-off-by: Maciej W. Rozycki > > Fixes: 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init") > > Cc: stable@vger.kernel.org > > Reviewed-by: Jiaxun Yang > > Tested-by: Jiaxun Yang # Boston I6400, M5150 sim > > Signed-off-by: Thomas Bogendoerfer > > > > Reverting this commit, make the RB532 boot. I need the UART patch, too. > > FYI, this commit is buggy and has been fixed by commit 841ecc979b18d > ("MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow"). But if you take a look at the dmesg, I am using latest Linux GIT master, which includes this commit. But still it is failing for me. best regards Waldemar