From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: Daniel Palmer <daniel@0x0f.com>
Cc: alison.wang@nxp.com, angelo@kernel-space.org, trini@konsulko.com,
me@ziyao.cc, jserv@ccns.ncku.edu.tw, eleanor15x@gmail.com,
u-boot@lists.denx.de
Subject: Re: [PATCH v2 2/4] m68k: Add support for M68040 CPU
Date: Mon, 29 Dec 2025 21:27:13 +0800 [thread overview]
Message-ID: <aVKBsTYOxu82pFHs@google.com> (raw)
In-Reply-To: <CAFr9PXkL8pDrtM86pmaw3U9RXCH2z-33X4hjqKUiJQAnQk-K0g@mail.gmail.com>
Hi Daniel,
On Mon, Dec 29, 2025 at 10:54:45AM +0900, Daniel Palmer wrote:
> Hi Kuan-Wei,
>
> On Mon, 29 Dec 2025 at 04:29, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> > > Connecting GDB and single stepping to work out where it is going would
> > > be helpful.
> >
> > I did attempt to investigate this using gdb, but unfortunately, the
> > root cause remains elusive. memset itself appears to execute correctly,
> > successfully zeroing out the global data. However, using it seems to
> > trigger a side effect where initcall_run_f() returns (which should not
> > happen), leading to the hang.
>
> Maybe a QEMU bug? If I get some time I will try to reproduce it.
>
> > > Since there is now a goldfish RTC driver upstream
> > > (drivers/rtc/goldfish_rtc.c) we could take the timer part from my
> > > version (https://github.com/fifteenhex/u-boot/blob/mc68000/drivers/rtc/goldfish_timer.c)
> > > and supply a real timer to the board. Right now I think anything that
> > > uses delays will get stuck constantly reading back 0?
> >
> > My original plan was to focus on a minimal boot to shell support in
> > this series and add rtc/timer support later. However, if you prefer to
> > have them included in this series, I am fine with that.
>
> I looked at adding the timer parts of my "goldfish rtc" driver to the
> upstream one and it's not very clean.
> So I have removed the unfinished RTC bits from my driver and moved the
> whole thing to drivers/timers/.
> That seems like a better way to go. I think having working delays etc
> would be nice even for the initial support.
> I guess if you send your initial stuff and someone asks "why is there
> no timer?" you can tell them I'll send a driver for that in the next
> series?
Sure, I will add rtc and timer support in the next version. Thanks!
>
> > Since the timer driver is authored by you, I assume I should add
> > Co-developed-by and Signed-off-by tags with your name to credit you
> > properly. I wanted to explicitly ask for your permission first.
>
> If there is anything in my branch you find useful you have my
> permission to just copy and paste without adding any tags etc.
> Credit is nice but I don't really mind.
Got it. Thanks.
>
> > Also, regarding the tags, would you prefer I send the integrated patch
> > to you privately for verification before posting v3, or is posting it
> > directly to the list fine?
>
> Can you put the branch on github or something for me? If you send me
> patches I'm going to have to import them to my local checkout to look
> at so if you have a branch I can access that's less steps. :D
Sure, I will push the series to github and share the link.
Regards,
Kuan-Wei
next prev parent reply other threads:[~2025-12-29 14:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-26 17:53 [PATCH v2 0/4] m68k: Add support for QEMU virt machine Kuan-Wei Chiu
2025-12-26 17:53 ` [PATCH v2 1/4] serial: Add Goldfish TTY driver Kuan-Wei Chiu
2025-12-27 2:07 ` Yao Zi
2025-12-27 14:06 ` Kuan-Wei Chiu
2025-12-26 17:53 ` [PATCH v2 2/4] m68k: Add support for M68040 CPU Kuan-Wei Chiu
2025-12-28 1:28 ` Daniel Palmer
2025-12-28 19:29 ` Kuan-Wei Chiu
2025-12-29 1:54 ` Daniel Palmer
2025-12-29 13:27 ` Kuan-Wei Chiu [this message]
2025-12-26 17:53 ` [PATCH v2 3/4] board: Add QEMU m68k virt board support Kuan-Wei Chiu
2025-12-28 1:16 ` Daniel Palmer
2025-12-28 19:13 ` Kuan-Wei Chiu
2025-12-29 1:42 ` Daniel Palmer
2025-12-29 13:44 ` Kuan-Wei Chiu
2025-12-31 3:20 ` Daniel Palmer
2025-12-26 17:54 ` [PATCH v2 4/4] CI: Add test jobs for QEMU m68k virt machine Kuan-Wei Chiu
2025-12-26 18:09 ` Tom Rini
2025-12-26 18:57 ` Kuan-Wei Chiu
2025-12-26 18:59 ` Tom Rini
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=aVKBsTYOxu82pFHs@google.com \
--to=visitorckw@gmail.com \
--cc=alison.wang@nxp.com \
--cc=angelo@kernel-space.org \
--cc=daniel@0x0f.com \
--cc=eleanor15x@gmail.com \
--cc=jserv@ccns.ncku.edu.tw \
--cc=me@ziyao.cc \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.