[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFr9PXm5v8K9K0V474kNBnNfF8dK25-MA2PDZns0CbxcUkU8EA@mail.gmail.com>
Date: Thu, 9 Jan 2025 23:08:23 +0900
From: Daniel Palmer <daniel@...f.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: fthain@...ux-m68k.org, linux-m68k@...ts.linux-m68k.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] m68k goes DT
Hi Geert,
On Thu, 9 Jan 2025 at 19:31, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Daniel,
>
> On Sun, Jan 5, 2025 at 8:15 AM Daniel Palmer <daniel@...f.com> wrote:
> > - The head.S code sometimes gets stuck setting up the mmu on my MVME147 when
> > the kernel binary layout changes. I thought for a long time my new code was
> > wrong but then discovered just making the kernel bigger by adding some printk()s
> > also caused it.
>
> What is your kernel size? Perhaps the code to map 8 or 16 MiB of
> the first memory chunk doesn't work on 68030?
Kernel is 3.something MiB
> There could also be some alignment issues. IIRC, there is code that
> expects the FDT to be 8-byte aligned.
I thought that too but it seems to be something else. I worked out
that for some reason head.S writes values to memory but reads back the
old value in some cases. The MMU code was not working correctly
because it was constantly clearing the page where it was putting the
data.
I then realised I wasn't disabling the I/D caches in u-boot so I added
that and it started working more reliably but it only boots every time
if I disable the caches before doing the stuff to load the ELF into
memory. So there is something funky going on in my u-boot I think and
head.S might be fine.
Anyhow,.. I have everything including the timer and interrupts setup
via DT on the MVME147 now.
Cheers,
Daniel
Powered by blists - more mailing lists