Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[J. Mayer]

Hi,

Sorry for the delay...

On Fri, 2007-10-19 at 12:57 -0500, Milton Miller wrote: 
> On Oct 18, 2007, at 6:46 PM, J. Mayer wrote:
> > On Thu, 2007-10-18 at 19:12 -0500, Rob Landley wrote:
[...]
> Rob was complaining he needed arch ppc to boot prep qemu but  
> kernel_headers only worked on powerpc.  Rob choose prep because the  
> header on the prep kernel was the only one that satisfied Open Hackware  
> when supplied to -kernel.  About this time Dave Gibson started code to  
> run prep hardware under powerpc.  It had several assumptions on what  
> the machine looked like.  As I remember it, I tried Dave's port on the  
> qemu 0.6.2 found on the Knoppix 4.0.2 dvd and caused qemu to segv.  I  
> was not prepared to debug qemu; I assumed the assumptions were not met.
> 
> Taking a look at Open Hackware 0.4, it appears that it treats the  
> memory given to -kernel as a block device.  That makes no sense to me.   
> I would expect it to treat the memory as the file loaded from the block  
> device.

This seems very common and useful to me to treat memory the same way you do 
with any block device. You can then have RAM disks, MTD, ... That's the idea 
behind it, even if the current implementation may not properly reflect it.
It's even more logical to treat the PreP kernel image as a bloc device as it is 
exactly a bloc device image dump...

>   Seeing that no updates to Open Hackware had been made in  
> years, and that it only pretended to have a open firmware client  
> interface and contained a mostly useless rtas (eg no pci config  
> methods), I decided to try bypassing it and just give the kernel what  
> it was looking for: a description of the hardware.

OpenFirmware should not be required to boot a PreP system, as it is only
an option of the platform. The residual data should be sufficient for
any OS, if we follow the specification. RTAS is not used on PreP, as far
as I know, it seems to be useful mostly when running in a virtual
partition but this is not supported by Qemu for now.

> 
> I choose to continue with prep because I knew the expected hardware  
> much better than pmac (the heathrow emulation).  I started by mining  
> Open Hackware 0.4 for information describing the hardware and its  
> startup.  I found the entry point was 0xfffffffc and after a bit of  
> experimentation I found qemu required the rom to be 512k and was read  
> only.  I found that since there were no caches I could do IO to serial  
> in real mode, which meant I didn't have to decide what to map via bats.  

I guess you found most of the useful informations, there !

[...]


> > I have to admit I never put the focus on trying to solve this issue,  
> > has
> > I usually use Mac99 or PowerPC 405 targets for tests and that PreP
> > machines are long obsolete and the heathrow target does not reflect any
> > real machine. But this is to be solved, for sure.
> 
>  From the patch description you inserted a openpic between the 8259 and  
> the cpu.  If this is true, at a minimum it will require this to be  
> described to be in the device tree for linux (or in the prep residual  
> data in general for hackware).  My qemu linux code wasn't expecting an  
> openpic so it would need to adjust; or perhaps David's kernel code  
> would now work.

There is no OpenPIC in the Qemu PreP target. There could be one, but
currently, there is only one i8259, when there should be 2, cascaded...
(maybe some of the IRQ problems we have come from the fact we don't have
this second IRQ controller ?).
The patch did add a description of what I called the 'internal PowerPC
interrupt controller', which in fact is the emulation of the PowerPC bus
interface. For the PreP target, only the 6xx bus is supported. The also
added proper connection between the Mac99 target OpenPIC controller and
the PowerPC input pins and should also provide the connection between
the i8529 output pin and the PowerPC IRQ input pin for the PreP target.
I realized some times ago that the connections between the heathrow PIC
and the PowerPC input pins are not emulated, but there seem to be more
problems in the heathrow emulation.

[....]

> > If the proposed ROM image is best suitable to make PreP target run (and
> > as I don't spend a lot of time hacking OHW those days), it may also be
> > interesting to add a ppc_prep_rom.bin to the repository... In fact, it
> > was maybe not a good idea to try to use the same BIOS image on all
> > PowerPC targets...
> 
> The code has drawbacks, as I mentioned.  Its very linux specific and 
> the only error it finds is no load segement in the presumed elf header. 
>   It wouldn't be that hard to add some error checking and even print 
> error to the serial.  The code itself is not platform specific but the 
> device tree attached to it is.  As I said, we could link multiple 
> copies together (one for each platform) and search until we got the 
> right one; or just search trees based on the platform with the fixups 
> in code specific to that tree.   In that regard, this would be an 
> option to use when using -kernel instead of being tied to the prep 
> platform.

My way of thinking is:
if your BIOS image allows one to take any kernel that would boot on a
real PreP machine and make it boot directly with Qemu without any
modification, we have to use it. If you need to use a hacked kernel in
order to be able to boot it, then we'd better use OHW that is able to
boot 2.4 and 2.6 kernels, once the bugs to make them build properly for
PreP are fixed.

-- 
J. Mayer <address@hidden>
Never organized