From: "Rong Zhang" <rongrong@oss.cipunited.com>
To: "Waldemar Brodkorb" <wbx@openadk.org>,
"Jonas Gorski" <jonas.gorski@gmail.com>
Cc: "Jiaxun Yang" <jiaxun.yang@flygoat.com>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"Rong Zhang" <i@rong.moe>
Subject: Re: serial console on Mikrotik RB532 non-working
Date: Thu, 05 Feb 2026 14:27:10 +0800 [thread overview]
Message-ID: <c80062a1b781ff256426d659ab327654174177d1.camel@oss.cipunited.com> (raw)
In-Reply-To: <aYN1_mED5-IiKC4E@waldemar-brodkorb.de>
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 <wbx@openadk.org> wrote:
> > >
> > > Hi Jonas,
> > > Jonas Gorski wrote,
> > >
> > > > Hi,
> > > >
> > > > On Tue, Feb 3, 2026 at 7:25 PM Waldemar Brodkorb <wbx@openadk.org> 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 <bood|bad>, 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 <macro@orcam.me.uk>
> 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 <macro@orcam.me.uk>
> Fixes: 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init")
> Cc: stable@vger.kernel.org
> Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> Tested-by: Jiaxun Yang <jiaxun.yang@flygoat.com> # Boston I6400, M5150 sim
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
>
> 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").
Thanks,
Rong
> Attached is the dmesg from the device.
>
> Anyone knows how to fix this issue?
>
> best regards
> Waldemar
>
next prev parent reply other threads:[~2026-02-05 6:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-01 18:39 serial console on Mikrotik RB532 non-working Waldemar Brodkorb
2026-02-03 15:24 ` Jiaxun Yang
2026-02-03 15:28 ` Jiaxun Yang
2026-02-03 18:25 ` Waldemar Brodkorb
2026-02-04 10:14 ` Jonas Gorski
2026-02-04 11:19 ` Waldemar Brodkorb
2026-02-04 11:33 ` Jonas Gorski
2026-02-04 16:38 ` Waldemar Brodkorb
2026-02-05 6:27 ` Rong Zhang [this message]
2026-02-05 7:29 ` Waldemar Brodkorb
2026-02-21 9:23 ` Waldemar Brodkorb
2026-02-21 10:28 ` Maciej W. Rozycki
2026-02-21 16:08 ` Waldemar Brodkorb
2026-02-12 7:35 ` Waldemar Brodkorb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c80062a1b781ff256426d659ab327654174177d1.camel@oss.cipunited.com \
--to=rongrong@oss.cipunited.com \
--cc=i@rong.moe \
--cc=jiaxun.yang@flygoat.com \
--cc=jonas.gorski@gmail.com \
--cc=linux-mips@vger.kernel.org \
--cc=wbx@openadk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).