On Mon, Jan 30, 2012 at 02:31:15PM -0700, Grant Likely wrote:
> On Mon, Jan 30, 2012 at 05:42:12PM +, Dave Martin wrote:
> > On Wed, Jan 25, 2012 at 05:43:16PM +, Pawel Moll wrote:
> > > On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
> > > > > Ok, /include/ "skeleton.dtsi" is gone t
On Mon, Jan 30, 2012 at 05:42:12PM +, Dave Martin wrote:
> On Wed, Jan 25, 2012 at 05:43:16PM +, Pawel Moll wrote:
> > On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
> > > > Ok, /include/ "skeleton.dtsi" is gone then :-)
> > >
> > > The problem wasn't with including skeleton.dtsi.
On Wed, Jan 25, 2012 at 05:43:16PM +, Pawel Moll wrote:
> On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
> > > Ok, /include/ "skeleton.dtsi" is gone then :-)
> >
> > The problem wasn't with including skeleton.dtsi. With
> > CONFIG_ARM_ATAG_DTB_COMPAT the zImage decompressor modifies t
On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
> > Ok, /include/ "skeleton.dtsi" is gone then :-)
>
> The problem wasn't with including skeleton.dtsi. With
> CONFIG_ARM_ATAG_DTB_COMPAT the zImage decompressor modifies the appended
> DTB using information from the ATAGs (see atags_to_fdt()
On Thu, Jan 19, 2012 at 11:09 AM, Nicolas Pitre wrote:
> On Thu, 19 Jan 2012, Grant Likely wrote:
>
>> On Thu, Jan 19, 2012 at 10:50 AM, Russell King - ARM Linux
>> wrote:
>> > On Thu, Jan 19, 2012 at 05:27:15PM +, Pawel Moll wrote:
>> >> On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
On Thu, 19 Jan 2012, Grant Likely wrote:
> On Thu, Jan 19, 2012 at 10:50 AM, Russell King - ARM Linux
> wrote:
> > On Thu, Jan 19, 2012 at 05:27:15PM +, Pawel Moll wrote:
> >> On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
> >> > The problem wasn't with including skeleton.dtsi.
> >>
>
On Thu, Jan 19, 2012 at 10:50 AM, Russell King - ARM Linux
wrote:
> On Thu, Jan 19, 2012 at 05:27:15PM +, Pawel Moll wrote:
>> On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
>> > The problem wasn't with including skeleton.dtsi.
>>
>> Including as it is creates two device_type="memory"
On Thu, Jan 19, 2012 at 05:27:15PM +, Pawel Moll wrote:
> On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
> > The problem wasn't with including skeleton.dtsi.
>
> Including as it is creates two device_type="memory" nodes, one with
> regs=<0 0>, which is definitely wrong.
>
> > With
>
On Thu, 2012-01-19 at 17:00 +, David Vrabel wrote:
> The problem wasn't with including skeleton.dtsi.
Including as it is creates two device_type="memory" nodes, one with
regs=<0 0>, which is definitely wrong.
> With
> CONFIG_ARM_ATAG_DTB_COMPAT the zImage decompressor modifies the appended
On Thu, Jan 19, 2012 at 05:00:56PM +, David Vrabel wrote:
> I don't expect any real production vexpress system to use this config
> options
I do - _if_ I decide to try DT on my Versatile Express. That'll be
with the existing boot setup, which will be ATAG based.
__
On 19/01/12 14:51, Pawel Moll wrote:
> On Thu, 2012-01-19 at 14:01 +, Rob Herring wrote:
>> On 01/19/2012 07:43 AM, Pawel Moll wrote:
>>> On Thu, 2012-01-19 at 13:34 +, Rob Herring wrote:
> You're right - the skeleton.dtsi contains "memory" mode... Funnily
> enough originally I was
On Thu, 2012-01-19 at 14:01 +, Rob Herring wrote:
> On 01/19/2012 07:43 AM, Pawel Moll wrote:
> > On Thu, 2012-01-19 at 13:34 +, Rob Herring wrote:
> >>> You're right - the skeleton.dtsi contains "memory" mode... Funnily
> >>> enough originally I was using that name, but then Rob Herring su
On 01/19/2012 07:43 AM, Pawel Moll wrote:
> On Thu, 2012-01-19 at 13:34 +, Rob Herring wrote:
>>> You're right - the skeleton.dtsi contains "memory" mode... Funnily
>>> enough originally I was using that name, but then Rob Herring suggested
>>> changing it to @8000, which seemed reasonable.
On Thu, 2012-01-19 at 13:34 +, Rob Herring wrote:
> > You're right - the skeleton.dtsi contains "memory" mode... Funnily
> > enough originally I was using that name, but then Rob Herring suggested
> > changing it to @8000, which seemed reasonable.
> >
> > Now I wonder - is the "memory" nod
On 01/19/2012 07:27 AM, Pawel Moll wrote:
> On Tue, 2012-01-10 at 14:21 +, David Vrabel wrote:
>> On 15/12/11 14:02, Pawel Moll wrote:
>>> This patch adds Device Tree file for the CoreTile Express A15x2
>>> (V2P-CA15) with Test Chip 1.
>>
>> This doesn't work as-is with the software model as ac
On Tue, 2012-01-10 at 14:21 +, David Vrabel wrote:
> On 15/12/11 14:02, Pawel Moll wrote:
> > This patch adds Device Tree file for the CoreTile Express A15x2
> > (V2P-CA15) with Test Chip 1.
>
> This doesn't work as-is with the software model as accessing some of the
> peripherals that aren't
On 15/12/11 14:02, Pawel Moll wrote:
> This patch adds Device Tree file for the CoreTile Express A15x2
> (V2P-CA15) with Test Chip 1.
This doesn't work as-is with the software model as accessing some of the
peripherals that aren't modeled will cause an exception. Is it worth
having a device tree
This patch adds Device Tree file for the CoreTile Express A15x2
(V2P-CA15) with Test Chip 1.
As the chip's GIC has 160 interrupt inputs and equivalent SMM
(FPGA) has GIC synthesised with 256 interrupts, NR_IRQS is
increased.
Signed-off-by: Pawel Moll
---
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.
18 matches
Mail list logo