On 23.01.2014, at 01:08, Scott Wood <scottw...@freescale.com> wrote:
> On Mon, 2014-01-20 at 00:44 +0100, Alexander Graf wrote:
>> The GUTS device is used by system software to find out about hardware
>> details of the current system.
>>
>> We only emulate the bare minimum to be able to reboot a guest which is
>> not sufficient to make u-boot happy.
>>
>> Add a few more registers to our portfolio with dummy values.
>>
>> Signed-off-by: Alexander Graf <ag...@suse.de>
>> ---
>> hw/ppc/mpc8544_guts.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/hw/ppc/mpc8544_guts.c b/hw/ppc/mpc8544_guts.c
>> index a10abe9..af8c742 100644
>> --- a/hw/ppc/mpc8544_guts.c
>> +++ b/hw/ppc/mpc8544_guts.c
>> @@ -25,6 +25,8 @@
>> #define MPC8544_GUTS_RSTCR_RESET 0x02
>>
>> #define MPC8544_GUTS_ADDR_PORPLLSR 0x00
>> +#define PORPLLSR_SYS_RATIO_MAX 0x3e
>> +#define PORPLLSR_CPU0_RATIO_MAX (0x3f << 16)
>> #define MPC8544_GUTS_ADDR_PORBMSR 0x04
>> #define MPC8544_GUTS_ADDR_PORIMPSCR 0x08
>> #define MPC8544_GUTS_ADDR_PORDEVSR 0x0C
>> @@ -36,6 +38,7 @@
>> #define MPC8544_GUTS_ADDR_GPINDR 0x50
>> #define MPC8544_GUTS_ADDR_PMUXCR 0x60
>> #define MPC8544_GUTS_ADDR_DEVDISR 0x70
>> +#define DEVDISR_DISABLED_NONE 0x0
>> #define MPC8544_GUTS_ADDR_POWMGTCSR 0x80
>> #define MPC8544_GUTS_ADDR_MCPSUMR 0x90
>> #define MPC8544_GUTS_ADDR_RSTRSCR 0x94
>> @@ -73,6 +76,15 @@ static uint64_t mpc8544_guts_read(void *opaque, hwaddr
>> addr,
>>
>> addr &= MPC8544_GUTS_MMIO_SIZE - 1;
>> switch (addr) {
>> + case MPC8544_GUTS_ADDR_PORPLLSR:
>> + value = PORPLLSR_SYS_RATIO_MAX | PORPLLSR_CPU0_RATIO_MAX;
>> + break;
>> + case MPC8544_GUTS_ADDR_PORDEVSR:
>> + value = 0;
>> + break;
>> + case MPC8544_GUTS_ADDR_DEVDISR:
>> + value = DEVDISR_DISABLED_NONE;
>> + break;
>
> But we don't actually have most of these devices that you're claiming
> aren't disabled via DEVDISR -- and with the paravirt target, what do
> these registers even mean?
For PORDEVSR and DEVDISR I agree - I'll just remove the code in u-boot that
accesses them. It's all in board code anyway.
For PORPLLSR things are more complicated. I'm not really a big fan of touching
speed.c and adding complicated and hard to test preprocessor statements. So how
about we leave that one in?
Alex
>
> I'd rather see U-Boot not touch these registers for the QEMU target,
> rather than returning arbitrary values.
>
> -Scott
