linux-kernel - RE: [PATCH 10/56] microblaze_v2: Generic dts file for platforms

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]

Message-Id: <1210032615.5798.174.camel@localhost>
Date:	Tue, 06 May 2008 10:10:15 +1000
From:	John Williams <john.williams@...alogix.com>
To:	Stephen Neuendorffer <stephen.neuendorffer@...inx.com>
Cc:	monstr@...nam.cz, linux-kernel@...r.kernel.org, arnd@...db.de,
	linux-arch@...r.kernel.org, John Linn <linnj@...inx.com>,
	matthew@....cx, will.newton@...il.com, drepper@...hat.com,
	microblaze-uclinux@...e.uq.edu.au, grant.likely@...retlab.ca,
	Michal Simek <monstr@...str.eu>
Subject: RE: [PATCH 10/56] microblaze_v2: Generic dts file for platforms

On Mon, 2008-05-05 at 16:32 -0700, Stephen Neuendorffer wrote:
> The .dts is not board specific, it's design specific.  

Sure.  I'm not sure how that changes where the .DTS files should be
stored.

I find it extremely helpful from a configuration management point of
view to cluster together all of the platform-specific code and data.  I
also think it simplifies things for users, and that makes my life easier
in answering questions on the MicroBlaze list.

> In my opinion,
> this is not something that 'a vendor might maintain multiple versions
> of': instead it is in most cases simply fundamental to the FPGA design
> flow.

Sure it is.  Here's an ML505 design using the DVI video out.  Here's one
using the LL_TEMAC in SGMII mode.  Multiple designs, same board, all
will use the same board init but different DTS files.

These could be thrown down in /boot along with every other tree, but
why?  They have nothing in common with the other files down there, and
everything in common with the board/design-specific code.

Am I missing something?

>   In fact, in most cases, I'd like to make the .dts file part of
> the bitstream and not compiled into the kernel.

Well, I've just run out of BRAM on a V5LX50T design so please don't ask
for more of it to store a DTC! :)  Or do you mean to piggyback on the
tail of the configuration stream and read with some kind of JTAG user
code?

> Although powerpc has a bit more boot-time complexity than the microblaze
> does currently, I think it makes alot of sense to have some consistency
> here, and there is already a pattern to follow here which nicely
> orthogonalizes multiple .dts files for the same platform code.

arch/powerpc/boot is building a bootloader, so maybe that's why .dts
files belong there.  The bootloader is really the only thing that cares
about them as objects.  Once the kernel starts, it's just dereferencing
a pointer that happens to point to a datastructure it understands (or
copying it as a blob before doing same).

In fact, you could mount an argument that .dts files don't belong
anywhere near the MicroBlaze kernel, since our build process never
actually touches them.  

cheers,

John

--
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/