Hi Daniel,
On Sun, Dec 28, 2025 at 10:28:59AM +0900, Daniel Palmer wrote:
> Hi Kuan-Wei,
>
> On Sat, 27 Dec 2025 at 02:54, Kuan-Wei Chiu <[email protected]> wrote:
> > diff --git a/arch/m68k/cpu/m680x0/cpu.c b/arch/m68k/cpu/m680x0/cpu.c
> > new file mode 100644
> > index 00000000000..15e0c30980a
> > --- /dev/null
> > +++ b/arch/m68k/cpu/m680x0/cpu.c
>
> > +void m68k_virt_init_reserve(ulong base)
> > +{
>
> > + /* FIXME: usage of memset() here caused a hang on QEMU m68k virt. */
> > + for (i = 0; i < sizeof(*gd_ptr); i++)
> > + p[i] = 0;
>
> 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.
>
> > +void relocate_code(ulong sp, struct global_data *new_gd, ulong relocaddr)
> > +{
> > + board_init_r(new_gd, relocaddr);
> > +}
>
> I have this working so at a later date we can copy/paste that code and
> clean it up.
That sounds great. :)
I look forward to integrating that in the future.
>
> > +unsigned long timer_read_counter(void) { return 0; }
>
> 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.
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.
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?
>
> > +void __udelay(unsigned long usec) {}
>
> Or maybe delays just won't happen?
I confirmed that delays do not occur during the boot to shell sequence.
They would only be triggered if specific commands (like sleep 5) are
executed after booting to shell.
Regards,
Kuan-Wei
