[Qemu-devel] [GSoC?] Board autoconfiguration based on DTB info

[Qemu-devel] [GSoC?] Board autoconfiguration based on DTB info

[Alexander Monakov]

Hello,

Is it feasible to consume a DTB file in Qemu itself to make the board match the
DeviceTree hardware description? For example on Arm there are quite a few .dts
files in Linux tree for various boards; having a "generic" Arm board in Qemu that
could [to what degree?] emulate any of those sounds attractive in theory.

If that is technically possible, could that be a possible GSoC project idea?
I'm not a GSoC candidate, though. Hope it's not terribly off-topic.

Thanks.
Alexander

Re: [Qemu-devel] [GSoC?] Board autoconfiguration based on DTB info

[Peter Maydell]

On 22 January 2018 at 17:52, Alexander Monakov <amonakov@ispras.ru> wrote:
> Is it feasible to consume a DTB file in Qemu itself to make the board match the
> DeviceTree hardware description? For example on Arm there are quite a few .dts
> files in Linux tree for various boards; having a "generic" Arm board in Qemu that
> could [to what degree?] emulate any of those sounds attractive in theory.

This is an idea that people have suggested before, and it's certainly
an attractive theory, but unfortunately it doesn't work. The dtb files
contain enough information about the hardware to allow an OS (and in
particular Linux) to boot, but they don't include enough information
in all cases to allow QEMU to create the hardware in the correct way.

(There are some specialized situations where you can do it, for
instance if you're an SoC manufacturer and you're creating both
hardware and DTB and QEMU model yourself you can ensure that they're
all consistent and generated from the same original information and
the DTB has all the info QEMU needs in it; but we can't do it upstream
in the general case.)

Also, the main reason we don't have support for a wider range of Arm
boards is that all the devices are different -- it's no good being
able to read a dtb file that says there is a "mediatek,mt6797-uart" at
a particular address if we don't actually have a model of that UART.
Once you have all the device models, wiring up the SoC and board
level code in QEMU isn't really all that difficult (though we could
probably manage to make it a bit less boiler-platy).

thanks
-- PMM

Re: [Qemu-devel] [GSoC?] Board autoconfiguration based on DTB info

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

On Mon, Jan 22, 2018 at 05:59:00PM +0000, Peter Maydell wrote:
> On 22 January 2018 at 17:52, Alexander Monakov <amonakov@ispras.ru> wrote:
> > Is it feasible to consume a DTB file in Qemu itself to make the board match the
> > DeviceTree hardware description? For example on Arm there are quite a few .dts
> > files in Linux tree for various boards; having a "generic" Arm board in Qemu that
> > could [to what degree?] emulate any of those sounds attractive in theory.
> 
> This is an idea that people have suggested before, and it's certainly
> an attractive theory, but unfortunately it doesn't work. The dtb files
> contain enough information about the hardware to allow an OS (and in
> particular Linux) to boot, but they don't include enough information
> in all cases to allow QEMU to create the hardware in the correct way.
> 
> (There are some specialized situations where you can do it, for
> instance if you're an SoC manufacturer and you're creating both
> hardware and DTB and QEMU model yourself you can ensure that they're
> all consistent and generated from the same original information and
> the DTB has all the info QEMU needs in it; but we can't do it upstream
> in the general case.)
> 
> Also, the main reason we don't have support for a wider range of Arm
> boards is that all the devices are different -- it's no good being
> able to read a dtb file that says there is a "mediatek,mt6797-uart" at
> a particular address if we don't actually have a model of that UART.
> Once you have all the device models, wiring up the SoC and board
> level code in QEMU isn't really all that difficult (though we could
> probably manage to make it a bit less boiler-platy).

Thanks for explaining.

Alexander: Thanks for raising the idea for discussion!  If you have
anything else, please don't hesitate to post on qemu-devel.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]