Re: L4Re: Boot module copying and the MIPS Creator CI20

Paul Boddie <[email protected]> Wed, 10 May 2023 00:35:08 +0200
Newsgroups gmane.comp.micro-kernel.l4.devel
Message-ID <10331297.vn9PdWz9bU@jason>
On Monday, 8 May 2023 00:47:01 CEST Paul Boddie wrote:
> 
> I decided to test the old L4Re distribution with the new kernel and it seems
> to fail when clearing the status register in the kernel's start routine.
> Similarly, the new L4Re distribution (obtained using ham) seems to fail in
> the same way, either with the old or new kernels.

In fact, I was mistaken about this. The kernel does in fact run, and through 
laborious debugging efforts, I think I have established that it manages to 
hang when running Banner::init, more specifically during the underlying 
__v_printf routine, in that it enters that routine but never manages to 
successfully leave.

I did wonder if this might be due to the UART details not being successfully 
set up, but the bootstrap code seems to identify the appropriate region for 
the kernel options (defined by the .koptions section in the fiasco payload) 
and to copy the boot options into it appropriately. I cannot actually verify 
that the kernel reads the options correctly, though, since it doesn't produce 
any UART output and it appears that the UART may be part of the problem.

> Currently, I remain mystified by this problem. The bootstrap code has
> changed, but arguably not in substantial architecture-specific ways.
> Similarly, the kernel code remains unchanged in such ways, although the
> kernel payload is now somewhat bigger.

Regardless of the observations made above, the cache-related issues still 
apply, meaning that I have to flush the data cache after copying regions of 
the different payloads around, even though this was not necessary before.

I guess I will need to think of other techniques to deduce what is happening. 
It is obviously rather frustrating.

Paul