On 03/12/19 14:16, Thomas Huth wrote: > On 03/12/2019 14.04, Paolo Bonzini wrote: >> On 03/12/19 10:15, Thomas Huth wrote: >>>>>> Maybe we can rename this as read_boot_order_mm, and the previous >>>>>> read_boot_order_pc as read_boot_order_io. >>>>> >>>>> I don't think it makes much sense. This was completely specific to the >>>>> "prep" machine, even the "40p" machine seems to prefer fw_cfg nowadays. >>>>> So let's simply remove this old stuff. >>>>> >>>>>> diff --git a/tests/endianness-test.c b/tests/endianness-test.c >>>>>> index 58527952a5..2798802c63 100644 >>>>>> --- a/tests/endianness-test.c >>>>>> +++ b/tests/endianness-test.c >>>>>> @@ -35,7 +35,7 @@ static const TestCase test_cases[] = { >>>>>> { "mips64", "malta", 0x10000000, .bswap = true }, >>>>>> { "mips64el", "fulong2e", 0x1fd00000 }, >>>>>> { "ppc", "g3beige", 0xfe000000, .bswap = true, .superio = >>>>>> "i82378" }, >>>>>> - { "ppc", "prep", 0x80000000, .bswap = true }, >>>>>> + { "ppc", "40p", 0x80000000, .bswap = true }, >>>> >>>> ... here you access the Super I/O behind the PCI bridge via MMIO? >>> >>> The difference is that this is an *arbitrary* address in I/O space >>> there. >> >> No, it's the base address of the ISA space, to which the tests add the >> address of the pc-testdev device. It's not any different from the >> 0x80000000 in boot-order-test. > > Hmm, interesting. Why is it not necessary to set up the BARs of the > PCI-to-ISA bridge in this case?
I don't know. Maybe the machine doesn't need it, since these are not really BARs, since they are positive-decode addresses on the ISA bus. It may also be an emulation inaccuracy in the pc87312 ISA bridge. Paolo >> That said, I think it's a sensible objection that boot order doesn't >> come from m48t59 on 40p (does it not?). > Right. I'm also not an expert here, but I think the OpenBIOS on 40p > rather uses fw_cfg instead. > > Thomas >