Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 03/10] raven: move BIOS loading from board code to PCI host

[Hervé Poussineau]

Alexander Graf a écrit :
> On 23.12.2013, at 07:48, Hervé Poussineau <address@hidden> wrote:
>
> > Hi,
> >
> > Andreas Färber a écrit :
> > > Hi,
> > > Am 05.11.2013 00:09, schrieb Hervé Poussineau:
> > > > Raven datasheet explains where firmware lives in system memory, so do
> > > > it there instead of in board code. Other boards using the same PCI
> > > > host will not have to copy the firmware loading code.
> > > This part we had discussed and no one objected to the approach, so OK.
> > > > However, add a specific hack for Open Hack'Ware, which provides only
> > > > a 512KB blob to be loaded at 0xfff00000, but expects valid code at
> > > > 0xfffffffc (specific Open Hack'Ware reset instruction pointer).
> > > Was this part explained before? I don't spot the equivalent in the
> > > deleted code. If this is a new workaround, I would rather like to put it
> > > in a separate patch for bisecting (can offer to do that myself then).
> > > What are the symptoms? I am testing all these patches with OHW.
> > Old code does (error checking removed):
> > > > -            bios_size = get_image_size(filename);
> > > > -                bios_addr = (uint32_t)(-bios_size);
> > > > -                bios_size = load_image_targphys(filename, bios_addr,
> > Ie, bios_addr = -512KB (size of OHW blob) = 0xfff80000
> > and firmware is loaded in the range 0xfff80000-0xffffffff
> > OHW expects reset instruction pointer to be 0xfffffffc (not valid for 604, but 
> > that's not the point now), which contains a valid instruction.
> > Note that range 0xfff00000-0xfff7ffff is empty.
> >
> > Datasheet for raven says that firmware is at 0xfff00000, so I changed code to:
> > +#define BIOS_SIZE (1024 * 1024)
> > +                  bios_addr = (uint32_t)(-BIOS_SIZE);
> > +                  bios_size = load_image_targphys(filename, bios_addr,
> > +                                                  bios_size);
> > Ie, bios_addr = -1MB = 0xfff00000
> > and firmware is loaded in the range 0xfff00000-0xfff7ffff.
> > This doesn't work due to reset instruction pointer which now is pointing to 
> > empty memory, and symptoms are an empty screen on OHW.
> >
> > So, I'm adding this hack for OHW, to mirror the 0xfff00000-0xfff7ffff range to 
> > 0xfff80000-0xffffffff.
> >
> > So, this patch is a small functional change, as it adds a copy of the firmware 
> > in a new range 0xfff00000-0xfff7ffff, but I think we can live with it.
> >
> > We'll be able to remove it once we switch to another firmware which uses the 
> > right reset instruction pointer or whose size is 1MB.
>
> Couldn't we just make the ROM fill the upper part of the 1MB region when we see 
> it's smaller than 1MB? So that we pad at the bottom, not the top?
>
>   bios_size = get_image_size(filename);
>   if (bios_size < 0) {
>     // error handling
>   }
>   assert(bios_size <= (1*MB));
>   bios_addr = (uint32_t)(-bios_size);

I don't think that's a good idea, because the PReP cpus (601/604) have a 
reset vector at 0xfff00100. So you have to put some firmware at this 
address, even if firmware is smaller than 1MB.

OHW is the problem here, because it is less than 1MB and expects a reset 
vector at 0xfffffffc. That's why I want to put the hack outside raven 
chipset, in prep machine code.

Regards,

Hervé