qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-discuss] Custom board with DTS/DTB


From: Edgar E. Iglesias
Subject: Re: [Qemu-arm] [Qemu-discuss] Custom board with DTS/DTB
Date: Thu, 8 Dec 2016 13:02:18 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

On Wed, Dec 07, 2016 at 09:25:15AM +0000, Peter Maydell wrote:
> On 5 December 2016 at 17:51, James Hanley <address@hidden> wrote:
> > I'm moving my query to QEMU-Arm since it seems more applicable here.
> >    1) It seems that the -dtb option is not what I thought it was, but would
> > something like what I thought was the intent of the option be of value to
> > QEMU, that is to define the board support package for the system using DTC
> > to compile and pass into QEMU to define a generic board from the tree,
> > rather then defining the hardware within the code base of QEMU?  I
> > understand that there will always be some need for device support and
> > deginition from within the codebase, but this was more to allow the user to
> > define hardware board profiles without having to change source code.
> 
> The problem is that DTC is not designed for that job. It describes
> those aspects of the hardware that the kernel cares about, which
> overlaps with but isn't the same as the information that you would
> need to build a complete model of the hardware. So the idea has been
> suggested before but I think it would in practice be pretty unreliable
> (and for 99% of dtb files it would just not work anyway, because QEMU doesn't
> model the devices that the dtb describes).

Hi,

I mostly agree with what Peter says. Saying that, we (in the Xilinx tree) have
a system where we create a QEMU machine from a device-tree.
We've abandoned the idea of using a plain Linux DTS (with the Linux bindings)
for the reasons Peter mentions. Instead we use a set of extended bindings
+ we expose the QEMU device properties as they are.

So far we can describe everything we've needed, included complex memory
hierarchies with multiple address-spaces and memory translation/protection units
(IOMMUs, MPUs etc). Complex and multiple IRQ trees, power management structures
and signals to communicate between devices etc.

This is very useful to us but I'm not sure adding the current version of
our implementation makes sense to upstream.

A better option is perhaps to allow machine creation fully over QMP and
implement a DTS (could be XML or something else) parser outside of QEMU
that creates the machine over QMP. We could then support any kind of
format and a DTS/DTB instantiator could be written in python for example.

Best regards,
Edgar

> 
> >    2) Right now, I'm trying to run our embedded application (EmbOS RTOS with
> > DLib with our application support all targeted for Cortex-M4 MPU) and it
> > seems like QEMU (at least from variable names) wants to believe that under
> > boot.c and loader.c that the passed in application (using --kernel option)
> > is linux.
> 
> M-profile is different and doesn't generally use boot.c -- the board
> model code ends up calling armv7m_init() which treats kernel_filename
> as a random ELF file. (A profile --kernel will also treat an ELF
> file as an ELF file, it just has special casing to handle Linux kernels and
> assumes a raw binary is a kernel.)
> 
> If you're running one of the 2.8 rc candidates you can also use
> -device loader to load an arbitrary file (see docs/generic-loader.txt).
> 
> thanks
> -- PMM
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]