linux-kernel - Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 11 Nov 2012 14:47:13 -0600
From:	Rob Landley <rob@...dley.net>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Pantelis Antoniou <panto@...oniou-consulting.com>,
	Rob Herring <robherring2@...il.com>,
	Deepak Saxena <dsaxena@...aro.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Scott Wood <scottwood@...escale.com>,
	Tony Lindgren <tony@...mide.com>,
	Kevin Hilman <khilman@...com>, Matt Porter <mporter@...com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Felipe Balbi <balbi@...com>, Russ Dill <Russ.Dill@...com>,
	linux-omap@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving
 omap_devices to mach-omap2)

               On 11/09/2012 10:28:59 AM, Grant Likely wrote:
> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren  
> <swarren@...dotorg.org> wrote:
> > On 11/05/2012 01:40 PM, Grant Likely wrote:
> I'm not actually opposed to it, but it needs to be done in an elegant
> way. The DT data model already imposes more of a conceptual learning
> curve than I wish it did and I don't want to make that worse with a
> versioning model that is difficult to get ones head around.

Speaking of which...

I want to poke at board emulation in qemu, from scratch. Specifically,  
I want to start with an unpopulated board (just the processor), add a  
block of physical memory and a serial device, and boot an initramfs in  
there with stdin/stdout. Then I want to incrementally add an RTC,  
network card, and three block devices.

I'd like to define this board by giving qemu and the kernel the same  
device tree they can parse, and I'd like to _build_ this device tree so  
I understand what's in it. I'd like to repeat this exercize for arm,  
mips, ppc, x86, x86-64, sparc, sh4, and maybe other boards.

And I'd like to write up an article on doing it as a learning exercise.

Last time I checked, doing this wasn't possible. (qemu couldn't define  
a board by parsing a device tree, the kernel used the device tree as a  
guideline but it only really read data the drivers you linked in were  
expecting, the only documentation about what any of the nodes were was  
was read the other device trees as examples or read the source code of  
the drivers looking for data in the tree...)

Is it a more realistic project now? If so, where would I start? (Once  
upon a time I read the booting-without-of document, back when it lived  
in the ppc directory. It didn't really say what should go in any of the  
nodes.)

Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/