On Wed, May 19, 2010 at 08:46:19PM -0500, Timur Tabi wrote:
> On Wed, May 19, 2010 at 8:18 PM, David Gibson
> wrote:
>
> > Couldn't you use the configurable padding, but put the stuff to do it
> > into u-boot. i.e. repad the dtb at u-boot build time, rather than
> > u-boot runtime.
>
> That's w
On Wed, May 19, 2010 at 8:18 PM, David Gibson
wrote:
> Couldn't you use the configurable padding, but put the stuff to do it
> into u-boot. i.e. repad the dtb at u-boot build time, rather than
> u-boot runtime.
That's what I was trying to do. Take a look at this thread:
http://lists.denx.de/
On Wed, May 19, 2010 at 07:03:17PM -0500, Timur Tabi wrote:
> On Wed, May 19, 2010 at 5:44 PM, Benjamin Herrenschmidt
> wrote:
>
> > It's still not kernel business to have to deal with u-boot memory
> > allocation constraints.
>
> I agree, but it still makes sense to me to allow the padding to b
In message:
Timur Tabi writes:
: I'm stuck between a rock and a hard place, it seems. No one is
: willing to compromise on any of my ideas. It's hard to convince our
: BSP developers that they should be pushing more code upstream when I
: get so much resistance for a such a mundane
On Wed, 2010-05-19 at 19:03 -0500, Timur Tabi wrote:
> The problem is that the code which allocates a block for the fdt is
> completely distinct from the code that manipulates the fdt. We'd need
> to put in either some kind of funky callback mechanism, or insist that
> every fdt exist in a block o
On Wed, May 19, 2010 at 5:44 PM, Benjamin Herrenschmidt
wrote:
> It's still not kernel business to have to deal with u-boot memory
> allocation constraints.
I agree, but it still makes sense to me to allow the padding to be configurable.
> The padding in the kernel built is intended to
> make s
On Wed, 2010-05-19 at 16:33 -0500, Timur Tabi wrote:
> Benjamin Herrenschmidt wrote:
>
> >> So to accommodate future boards where more padding is needed, we make the
> >> option for the -p parameter configurable.
> >
> > Can't u-boot just allocate more space ?
>
> Yes and no. U-Boot has functio
On Wed, May 19, 2010 at 3:37 PM, Scott Wood wrote:
> On 05/19/2010 04:27 PM, Grant Likely wrote:
>>
>> On Mon, May 3, 2010 at 10:34 AM, Scott Wood
>> wrote:
>>>
>>> Grant Likely wrote:
>
> + // IPIC
> + // interrupts cell =
> + // sense va
On 05/19/2010 04:27 PM, Grant Likely wrote:
On Mon, May 3, 2010 at 10:34 AM, Scott Wood wrote:
Grant Likely wrote:
+ // IPIC
+ // interrupts cell =
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low asser
Benjamin Herrenschmidt wrote:
>> So to accommodate future boards where more padding is needed, we make the
>> option for the -p parameter configurable.
>
> Can't u-boot just allocate more space ?
Yes and no. U-Boot has functions to increase the size of an fdt, but these
functions can't be sure
On Mon, May 3, 2010 at 10:34 AM, Scott Wood wrote:
> Grant Likely wrote:
>>>
>>> + // IPIC
>>> + // interrupts cell =
>>> + // sense values match linux IORESOURCE_IRQ_* defines:
>>> + // sense == 8: Level, low assertion
>>> + /
On Wed, 2010-05-19 at 14:53 -0500, Timur Tabi wrote:
> Add the DTS_PADDING Kconfig option, which allows users and board defconfig
> files to specify a padding value when compiling device trees.
>
> When a device tree source (DTS) is compiled into a binary (DTB), a hard-coded
> padding of 1024 byte
On Wed, Apr 28, 2010 at 7:43 AM, Anatolij Gustschin wrote:
> On Mon, 01 Mar 2010 14:45:20 +1100
> Benjamin Herrenschmidt wrote:
>
>> On Sat, 2010-02-27 at 22:44 -1000, Mitch Bradley wrote:
>>
>> > As it turns out, I'm doing exactly that - exporting verbatim EDID
>> > data
>> > as the value of the
On Thu, May 6, 2010 at 6:36 PM, Dezhong Diao (dediao) wrote:
> Add the device tree support for all mips platforms.
>
The CONFIG_ARCH_HAS_DEVTREE_MEM related code is a little ugly since it
is certainly not multiplatform safe, but this is MIPS code which isn't
multiplatform anyway, so it doesn't co
On Wed, 19 May 2010, Jamie Lokier wrote:
> Nicolas Pitre wrote:
> > It is not up to the bootloader to "adjust" to the kernel. But rather
> > for the kernel to cope with the bootloader's provided information. If
> > the bootloader passes a specific machine ID with the ATAG list then the
> > ke
Nicolas Pitre wrote:
> It is not up to the bootloader to "adjust" to the kernel. But rather
> for the kernel to cope with the bootloader's provided information. If
> the bootloader passes a specific machine ID with the ATAG list then the
> kernel will use that, and if the bootloader passes a D
Add the DTS_PADDING Kconfig option, which allows users and board defconfig
files to specify a padding value when compiling device trees.
When a device tree source (DTS) is compiled into a binary (DTB), a hard-coded
padding of 1024 bytes is used (i.e. dtc command-line parameter "-p 1024").
Although
[ Complete boot description and proposal added at the end
for those interested. ]
On Wed, 19 May 2010, Grant Likely wrote:
> On Mon, May 17, 2010 at 10:34 PM, Nicolas Pitre wrote:
> > On Tue, 18 May 2010, Jeremy Kerr wrote:
> >> Some notes about this scheme:
> >>
> >> - This would break compa
In message:
Grant Likely writes:
: > They could also settle on a
: > fixed R1 value meaning "devtree platform".
: >
: > Or if a fixed "devtree platform" R1 is used, R2 could point directly
: > at the DT, no atag list in that specific case.
:
: My sticking point is I want there to be
Hi Jamie,
On Wed, May 19, 2010 at 10:45 AM, Jamie Lokier wrote:
> Grant Likely wrote:
>> Doing it this way means a non-compatible break in the interface. It
>> means that the bootloader needs to know what interface the kernel is
>> expecting for boot; information that is not readily available fr
Grant Likely wrote:
> On Tue, May 18, 2010 at 5:57 AM, Nicolas Pitre wrote:
> > On Tue, 18 May 2010, Jeremy Kerr wrote:
> >
> >> Hi Nicolas,
> >>
> >> > I think that, for the moment, it is best if the bootloader on already
> >> > existing subarchitectures where DT is introduced still preserve the
On Sun, May 16, 2010 at 11:47 AM, Albrecht Dreà wrote:
> Am 06.05.10 20:06 schrieb(en) Grant Likely:
>>
>> > I think, though, the whole stuff has been discussed in depth in
>> > February, so
>> > I do not understand why it's still pending as "new". Â Grant, did we miss
>> > something here?
>>
>>
On Wed, May 19, 2010 at 12:50 AM, David Gibson
wrote:
> On Tue, May 18, 2010 at 09:28:38PM -0400, Nicolas Pitre wrote:
>> On Wed, 19 May 2010, David Gibson wrote:
>>
>> > On Tue, May 18, 2010 at 08:24:06AM -0400, Nicolas Pitre wrote:
>> > > On Tue, 18 May 2010, David Gibson wrote:
>> > > > On Tue,
On Tue, May 18, 2010 at 7:41 PM, Jamie Lokier wrote:
> David Gibson wrote:
>> On Tue, May 18, 2010 at 08:24:06AM -0400, Nicolas Pitre wrote:
>> > On Tue, 18 May 2010, David Gibson wrote:
>> > > On Tue, May 18, 2010 at 01:24:43PM +0800, Jeremy Kerr wrote:
>> > > > Nicolas Pitre wrote:
>> [snip]
>>
On Wed, May 19, 2010 at 05:57:55AM -0600, Grant Likely wrote:
> side question: Do recent ARM SoCs provide any facility to reliably
> detected the silicon at run time? ie. like the processor (unique to
> core) and system (unique to SoC) id registers on PowerPC.
No.
Every SoC is effectively unique
On Tue, May 18, 2010 at 5:57 AM, Nicolas Pitre wrote:
> On Tue, 18 May 2010, Jeremy Kerr wrote:
>
>> Hi Nicolas,
>>
>> > I think that, for the moment, it is best if the bootloader on already
>> > existing subarchitectures where DT is introduced still preserve the
>> > already existing ability to b
On Mon, May 17, 2010 at 10:34 PM, Nicolas Pitre wrote:
> On Tue, 18 May 2010, Jeremy Kerr wrote:
>> Some notes about this scheme:
>>
>> - This would break compatibility with the existing boot interface:
>> bootloaders that expect a DT kernel will not be able to boot a non-DT kernel.
>> However, d
On Mon, May 17, 2010 at 8:54 PM, Jeremy Kerr wrote:
> Hi all,
>
> As we're getting closer to device tree support on ARM, I'd like to get some
> input on our proposed boot interface.
>
> Basically, I'd like to define how we pass the device tree from the bootloader
> to the kernel.
>
> My current me
Hi,
How to enable PCIe interrupt on device tree. I am using linux-2.6.30 on
MPC8640D based Target board.
-Thirumalai
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Nicolas,
> Exact. For example, on ARM the machine ID is also used to figure out
> the MMU mapping needed to be able to simply be able to debug the very
> early assembly boot stage when there isn't even a stack available.
I get the impression that this is the only thing that we need the io_pg_off
On Wed, May 19, 2010 at 02:41:18AM +0100, Jamie Lokier wrote:
> David Gibson wrote:
> > On Tue, May 18, 2010 at 08:24:06AM -0400, Nicolas Pitre wrote:
> > > On Tue, 18 May 2010, David Gibson wrote:
> > > > On Tue, May 18, 2010 at 01:24:43PM +0800, Jeremy Kerr wrote:
> > > > > Nicolas Pitre wrote:
>
Nicolas Pitre wrote:
...
Exact. For example, on ARM the machine ID is also used to figure out
the MMU mapping needed to be able to simply be able to debug the very
early assembly boot stage when there isn't even a stack available. While
this info is stored in the machine record, it is actuall
32 matches
Mail list logo
