In message [off-list ref] you wrote:
quoted
Where should we place the sources for the OF Flat Device
Tree source files? They used to be in U-Boot, but that
isn't happening any more.
Why ? While having device-tree's in zImages is good to handle firmwares
that can't pass them, I still think that the proper thing to do is to
have the firmware provide the DT to the kernel. Did Denk decide once for
all against having DTs passed by uboot at all ? In which case, it's
probably time to consider a fork...
Ben, you are mixing two things here.
I have nothing against U-Boot passing the DT to the kernel. On
contrary, if DT's are used, than I think this is how it should be
done.
It's just that I think that the DT *sources* should not be part of
the U-Boot soutrce tree, and that the DT should be in fact part of
the kernel images that gets booted by U-Boot.
This has been discussed before (see archives), and the agreement (?)
was to use U-Boot's multifile image format for this purpose, where
you can combine a Linux kenrel image with a DT image into one file
bootable by U-Boot.
Jon's question was where the source code of the DT should be placed.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is mind? No matter. What is matter? Never mind.
-- Thomas Hewitt Key, 1799-1875
It's just that I think that the DT *sources* should not be part of
the U-Boot soutrce tree, and that the DT should be in fact part of
the kernel images that gets booted by U-Boot.
Fair enough, I misunderstood.
This has been discussed before (see archives), and the agreement (?)
was to use U-Boot's multifile image format for this purpose, where
you can combine a Linux kenrel image with a DT image into one file
bootable by U-Boot.
Well, I would still like something else. For example, I'm vendor NetFoo
selling network appliances (ADSL modems, routers, wireless APs, ...).
A certain amount of my products are based on a very similar chipset
provided by vendor NarrowCom, same core, same ethernet cell, though my
devices have subtle differences in the various varieties of those chips
used and what other chips are put around on the board.
I want my devices to have a firmware that pass a DT to the kernel. That
DT is bolted into the firmware. In fact, it could be separate flash
blocks (especially if the flash has some small blocks) from the actual
firmware code but that does not really matter.
That way, I can distribute and maintain a single kernel image update
package as part of my software update/maintainance solution.
Now you might argue that the way to work around that is to distribute a
vmlinux + DT files and have the "installer" merge them together at flash
time. I don't disagree... that works... if the kernel is in flash. It's
a bit more annoying once you start having it on a removable support
though...
It's not _the_ only solution but it's something that I think should be
considered.
Now as far as having an official repository for the .dts files of boards
supported by the kernel, I suppose indeed that the kenrel tree is an as
good location as anything else.
Cheers,
Ben.
On Aug 9, 2006, at 11:05, Benjamin Herrenschmidt wrote:
quoted
It's just that I think that the DT *sources* should not be part of
the U-Boot soutrce tree, and that the DT should be in fact part of
the kernel images that gets booted by U-Boot.
Fair enough, I misunderstood.
quoted
This has been discussed before (see archives), and the agreement (?)
was to use U-Boot's multifile image format for this purpose, where
you can combine a Linux kenrel image with a DT image into one file
bootable by U-Boot.
Well, I would still like something else. For example, I'm vendor
NetFoo
selling network appliances (ADSL modems, routers, wireless APs, ...).
A certain amount of my products are based on a very similar chipset
provided by vendor NarrowCom, same core, same ethernet cell, though my
devices have subtle differences in the various varieties of those
chips
used and what other chips are put around on the board.
I want my devices to have a firmware that pass a DT to the kernel.
That
DT is bolted into the firmware. In fact, it could be separate flash
blocks (especially if the flash has some small blocks) from the actual
firmware code but that does not really matter.
That way, I can distribute and maintain a single kernel image update
package as part of my software update/maintainance solution.
I think you'll find that the changes Matt McClintock made to u-boot
make this quite possible. The dtb is kept separate, and passed in by
u-boot. If those patches are acceptable, they provide what you
want. If they aren't acceptable, we'd be happy to make changes. We
just need to know, one way or another.
Andy