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.
> +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.
> +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?
> +void __udelay(unsigned long usec) {}
Or maybe delays just won't happen?
Cheers,
Daniel
