On Tue, 2008-02-12 at 13:10 -0600, Scott Wood wrote:
Hmm? All I meant was that it'd be nice if there were an option in the
Linux mtd code to disable the look for another chip and cause a machine
check if it isn't there functionality. It was an aside from the
dts-variant issue.
Yeah,
On Feb 12, 2008 11:52 AM, Scott Wood [EMAIL PROTECTED] wrote:
On Mon, Feb 11, 2008 at 07:41:07PM -0500, Sean MacLennan wrote:
David Gibson wrote:
Err.. now I'm doubly confused. Initially I thought you'd need to
change the size part of reg somewhere, but your description above just
On Feb 12, 2008 8:44 AM, Timur Tabi [EMAIL PROTECTED] wrote:
Arnd Bergmann wrote:
On Tuesday 12 February 2008, David Gibson wrote:
Or to expand. It's relatively easy now to just include multiple nodes
in the tree and either delete or nop some of them out conditionally
using libfdt.
On Feb 12, 2008 12:45 PM, Timur Tabi [EMAIL PROTECTED] wrote:
Grant Likely wrote:
Then use a local version in the data; don't overload the purpose of
the dtb version.
I don't know what you mean by that.
I'm saying that the dtb version is to describe the binary format of
the dtb; not the
David Gibson wrote:
I can pretty much guarantee you that someone will find that
insufficient and want to expand the conditional representation. This
way madness lies.
Then let them. We can have version numbers associated with the conditional
expressions. If they want to make more complex
David Gibson wrote:
You don't. If your agent takes a dtb, dtb layout and agent must
match.
So what I would like to see is a way for the agent to validate the dtb. U-Boot
could currently validate the SOC's compatible field. However, if we add a
special node that contains rules for
On Tue, Feb 12, 2008 at 05:41:12PM -0600, Timur Tabi wrote:
David Gibson wrote:
I'm not sure I'm entirely happy about storing the fragments under a
special node - but certainly u-boot could do that if it wants. What
would certainly be ok is to store various fragments as separate blobs
David Gibson wrote:
I'm not sure I'm entirely happy about storing the fragments under a
special node - but certainly u-boot could do that if it wants. What
would certainly be ok is to store various fragments as separate blobs
and fold them together as necessary. Which reminds me, I meant to
On Tue, Feb 12, 2008 at 01:45:39PM -0600, Timur Tabi wrote:
Grant Likely wrote:
[snip]
That's not a dtb version issue. That is a dtb content issue.
Technically, that's true, but ...
It does
not warrant changing the dtb version number.
Then how do you solve the problem of passing a
On Tue, Feb 12, 2008 at 05:47:23PM -0600, Timur Tabi wrote:
David Gibson wrote:
I can pretty much guarantee you that someone will find that
insufficient and want to expand the conditional representation. This
way madness lies.
Then let them. We can have version numbers associated
On Tue, Feb 12, 2008 at 12:51:06PM -0600, Scott Wood wrote:
On Tue, Feb 12, 2008 at 11:36:33AM +1100, David Gibson wrote:
On Tue, Feb 12, 2008 at 01:21:44AM +0100, Arnd Bergmann wrote:
On Tuesday 12 February 2008, David Gibson wrote:
Or to expand. It's relatively easy now to just
On Feb 12, 2008 4:47 PM, Timur Tabi [EMAIL PROTECTED] wrote:
David Gibson wrote:
I can pretty much guarantee you that someone will find that
insufficient and want to expand the conditional representation. This
way madness lies.
Then let them. We can have version numbers associated with
On Feb 12, 2008 4:35 PM, David Gibson [EMAIL PROTECTED] wrote:
In fact, in one way of looking at it that's always what happens: the
dtb format is defined for passing hardware information from the
bootloader to the kernel; nothing else. Passing a dtb *into* the
bootloader is just a bootloader
On Tue, Feb 12, 2008 at 09:44:39AM -0600, Timur Tabi wrote:
Arnd Bergmann wrote:
On Tuesday 12 February 2008, David Gibson wrote:
Or to expand. It's relatively easy now to just include multiple nodes
in the tree and either delete or nop some of them out conditionally
using libfdt.
Grant Likely wrote:
On Feb 12, 2008 11:52 AM, Scott Wood [EMAIL PROTECTED] wrote:
It'd be nice if we could pass in a flag to tell it not to try to find
additional consecutive chips in the mapping... It's a shame to have
probable chips, and still have to know how big they are anyway.
That
Grant Likely wrote:
On Feb 12, 2008 8:44 AM, Timur Tabi [EMAIL PROTECTED] wrote:
Arnd Bergmann wrote:
On Tuesday 12 February 2008, David Gibson wrote:
Or to expand. It's relatively easy now to just include multiple nodes
in the tree and either delete or nop some of them out conditionally
On Feb 12, 2008 12:08 PM, Timur Tabi [EMAIL PROTECTED] wrote:
Grant Likely wrote:
On Feb 12, 2008 8:44 AM, Timur Tabi [EMAIL PROTECTED] wrote:
This requires coordination and
documentation, but id does not requires special formatting or
versioning of the device tree blob.
Unless the
On Tue, Feb 12, 2008 at 11:36:33AM +1100, David Gibson wrote:
On Tue, Feb 12, 2008 at 01:21:44AM +0100, Arnd Bergmann wrote:
On Tuesday 12 February 2008, David Gibson wrote:
Or to expand. It's relatively easy now to just include multiple nodes
in the tree and either delete or nop some of
[snip]
On Tue, Feb 12, 2008 at 01:08:24PM -0600, Timur Tabi wrote:
Grant Likely wrote:
On Feb 12, 2008 8:44 AM, Timur Tabi [EMAIL PROTECTED] wrote:
Arnd Bergmann wrote:
I think it
is a slippery slope to try and encode conditionals into the structure;
Perhaps, which is why I said it
Grant Likely wrote:
Then use a local version in the data; don't overload the purpose of
the dtb version.
I don't know what you mean by that.
I don't think it is yet possible to define a reasonable 'standard
manner' for massaging device trees. There are going to be a lot of
experiments and
Arnd Bergmann wrote:
On Tuesday 12 February 2008, David Gibson wrote:
Or to expand. It's relatively easy now to just include multiple nodes
in the tree and either delete or nop some of them out conditionally
using libfdt.
Yes, but what better place to store the conditions than in the
On Mon, Feb 11, 2008 at 07:41:07PM -0500, Sean MacLennan wrote:
David Gibson wrote:
Err.. now I'm doubly confused. Initially I thought you'd need to
change the size part of reg somewhere, but your description above just
convinced me you didn't (because you were essentially just shifting a
Arnd Bergmann wrote:
Maybe we can introduce a more generic way of having conditional
device nodes in the tree that get knocked out in the boot wrapper.
I've been thinking about doing just this for quite some time now. I've had a
few informal discussions without people about.
One idea is to
On Mon, Feb 11, 2008 at 07:41:07PM -0500, Sean MacLennan wrote:
David Gibson wrote:
Err.. now I'm doubly confused. Initially I thought you'd need to
change the size part of reg somewhere, but your description above just
convinced me you didn't (because you were essentially just shifting a
On Tue, Feb 12, 2008 at 01:21:44AM +0100, Arnd Bergmann wrote:
On Tuesday 12 February 2008, David Gibson wrote:
Or to expand. It's relatively easy now to just include multiple nodes
in the tree and either delete or nop some of them out conditionally
using libfdt. But the conditional logic
On Mon, Feb 11, 2008 at 08:07:14PM -0500, Sean MacLennan wrote:
David Gibson wrote:
But the partitions are all the same size, so in Map 2 there's a great
big gap between Env and U-boot? Or there's a great big gap before
FPGA?
There's a great big gap before the FPGA, 63M worth. Before
David Gibson wrote:
But the partitions are all the same size, so in Map 2 there's a great
big gap between Env and U-boot? Or there's a great big gap before
FPGA?
There's a great big gap before the FPGA, 63M worth. Before we got the
NAND working, we stored the kernel, the ramdisk image,
On Mon, Feb 11, 2008 at 11:57:10AM -0600, Timur Tabi wrote:
Arnd Bergmann wrote:
Maybe we can introduce a more generic way of having conditional
device nodes in the tree that get knocked out in the boot wrapper.
I've been thinking about doing just this for quite some time now. I've had
David Gibson wrote:
Err.. now I'm doubly confused. Initially I thought you'd need to
change the size part of reg somewhere, but your description above just
convinced me you didn't (because you were essentially just shifting a
4M map up into the high rather than low 4M of the 64M space). Now
On Sun, Feb 10, 2008 at 10:49:55PM -0500, Sean MacLennan wrote:
David Gibson wrote:
On Sun, Feb 10, 2008 at 09:40:19PM -0500, Sean MacLennan wrote:
David Gibson wrote:
This doesn't seem right. warp_fixup_one_nor() changes only the
partition's offset, so you're not changing
On Tue, Feb 12, 2008 at 10:54:09AM +1100, David Gibson wrote:
On Mon, Feb 11, 2008 at 11:57:10AM -0600, Timur Tabi wrote:
Arnd Bergmann wrote:
Maybe we can introduce a more generic way of having conditional
device nodes in the tree that get knocked out in the boot wrapper.
I've
On Tuesday 12 February 2008, David Gibson wrote:
Or to expand. It's relatively easy now to just include multiple nodes
in the tree and either delete or nop some of them out conditionally
using libfdt. But the conditional logic should be in the manipulating
agent (u-boot or bootwrapper or
On Fri, Feb 08, 2008 at 06:30:56PM -0500, Sean MacLennan wrote:
The Rev B warp is moving to a 4M NOR / 256M NAND flash setup from the
current 64M NOR / 64M NAND. I would like to keep support for the 64M NOR
so I modified the boot code to be a bit more dynamic. Here is the new
NOR parition
David Gibson wrote:
This doesn't seem right. warp_fixup_one_nor() changes only the
partition's offset, so you're not changing the size of any
partitions. If you're not going to actually use any of the extra
flash space with 64M, I can't see why you'd bother moving around the
partitions you
David Gibson wrote:
On Sun, Feb 10, 2008 at 09:40:19PM -0500, Sean MacLennan wrote:
David Gibson wrote:
This doesn't seem right. warp_fixup_one_nor() changes only the
partition's offset, so you're not changing the size of any
partitions. If you're not going to actually use any of
On Sun, Feb 10, 2008 at 09:40:19PM -0500, Sean MacLennan wrote:
David Gibson wrote:
This doesn't seem right. warp_fixup_one_nor() changes only the
partition's offset, so you're not changing the size of any
partitions. If you're not going to actually use any of the extra
flash space with
On Saturday 09 February 2008, Sean MacLennan wrote:
If anybody has suggestions on better ways to do this, fire away.
I guess the cleanest solution would be to include two complete device trees
for this platform, and then choose the correct one in cuboot-warp.c based
on the board revision.
The
Arnd Bergmann wrote:
I guess the cleanest solution would be to include two complete device trees
for this platform, and then choose the correct one in cuboot-warp.c based
on the board revision.
The obvious disadvantage of this is that you'd get two device trees
that you need to keep in sync
38 matches
Mail list logo
