On Tue, 7 Apr 2015 13:07:31 +0100
Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 7 April 2015 at 03:43, Shannon Zhao <zhaoshengl...@huawei.com>
> wrote:
> > The ACPI table entry:
> > Method (_CBA, 0, NotSerialized) // _CBA: Configuration
> > Base Address {
> > Return (0x3F000000)
> > }
> > Method (_CRS, 0, NotSerialized) // _CRS: Current
> > Resource Settings {
> > Name (RBUF, ResourceTemplate ()
> > {
> > WordBusNumber (ResourceProducer, MinFixed,
> > MaxFixed, PosDecode, 0x0000, // Granularity
> > 0x0000, // Range Minimum
> > 0x000F, // Range Maximum
> > 0x0000, // Translation Offset
> > 0x0010, // Length
> > ,, )
> > DWordMemory (ResourceProducer, PosDecode,
> > MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, //
> > Granularity 0x10000000, // Range Minimum
> > 0x3EFF0000, // Range Maximum
> > 0x00000000, // Translation Offset
> > 0x2EFF0000, // Length
>
> In all the other sections, the Length entry is (rangemax - rangemin)
> + 1, but in this one it is not, which suggests an error. Probably your
> rangemax here is wrong, since 0x3eff0000 is actually the first address
> in the IO window.
>
> (If ACPI is effectively describing the length of the range in
> two separate places, it's a shame it doesn't sanity check that
> they both agree...)
According to spec Range Minimum & Range Maximum are
lowest/highest possible base address
and have nothing to do with range size.
In x86 target that insanity was since the beginning, I guest it works
because no OS tries to use anything other than Range Minimum.
For example If guest has mapped region at Range Maximum, then access to
it would go beyond on real memory region mapped in QEMU.
In general Range Minimum & Range Maximum should be the same unless
HW side covers access up to Range Maximum + Length.
>
> -- PMM
>
